Agola wrote:
alexfru wrote:
Is there anything unclear in the manual?:
Quote:
when accessing a 16- and 32-bit I/O port, the operand-size attribute determines the port size.
Quote:
When operating in real-address mode, the default addressing and operand size is 16 bits.
Wow, I see it first time in the manual. Which volume is it? I usually use Volume 3-A as usually it explains what I need. And port IO sizes in manual looks everything is like I thought. I was using 16 bit IOs for these opcodes, too.
Intel® 64 and IA-32 Architectures Software Developer’s Manual
Combined Volumes: 1, 2A, 2B, 3A and 3B (May 2011 version)
Vol 1, section 3.3.5, 32-Bit and 16-Bit Address and Operand Sizes.
Vol 2A, section IN—Input from Port.
Learn to use the table of context and search.
Agola wrote:
But the processor doesnt trigger #GP for operand size override prefix, what should I do for it?
If you have a correctly encoded instruction (with a prefix or without) not trying to violate any protection, why should it?
Agola wrote:
Could acessing and testing CS:(EIP-1) with operand size override prefix work, as opcode prefixes are just before the opcode?
Bad idea. It can be the last byte of the preceding instruction or even data. Don't do that. If you get a real exception, the code address will point at the beginning of the offending instruction, not its middle. And then you parse the instruction, noting all of its prefixes, ModR/M, SIB and imm bytes and (d)words... I know, parsing x86 instructions sucks. If you're using a library to parse instructions, find out how to extract this info from it. It must be there or it wouldn't make sense to just tell you to emulate access without telling you the location or the size or both.