search

StanfordPL / x64asm

x86-64 assembler library
Apache License 2.0
465 stars 60 forks source link

Make it possible to specify an 8-bit displacement with a label #197

Closed bchurchill closed 9 years ago

bchurchill commented 9 years ago

Right now, if you want to generate a jump with a label, x64asm will always generate it with a 32-bit displacement. It should be possible though to use a different opcode to get an 8-bit displacement.

In the spreadsheet, there are correctly rows for three versions of a given jump instruction, with 8-, 16- and 32-bit offsets. (16 bits isn't valid in 64-bit mode). The Codegen tool then generates opcodes for each of these, and also an opcode for jumping to a label. That 'jump to label' "opcode" only corresponds to 32-bit offset opcode on the hardware.

In this ticket, Codegen will now generate two such fake "opcodes" for jumping to a label, one for 8-bit and the other for 32-bit offsets. By default, the parser will still choose the 32-bit version, but this can be overridden using a # OPC=nnnn in the comment, where nnnn is the index of the opcode in the x64asm table (or alternatively with a SIZE=n comment).

Now, when you assemble a Code, there's the possibility x64asm will fail if you've requested to use a jump with an 8-bit displacement but the jump target is more than 127 bytes away (in either direction). That means you need to check the return value of Assembler::finish().

bchurchill commented 9 years ago

A potential fix for this is in the issue-197 branch, but I'm not going to merge it into develop until it works in stoke.

stefanheule commented 9 years ago

Shouldn't we use something other than the index for the OPC comment? I'm worried that this is going to cause problems when we change the table again in some way, and suddenly the indices mean different things depending on the version of x64asm. Couldn't we just use the Opcode string representation? It would have the advantage of being stable across different versions of x64asm as well as being readable by humans.

bchurchill commented 9 years ago

Yeah, I was thinking about that. This behavior already is in existence in the parser but it's easy to change.

On 07/29/2015 07:09 AM, Stefan Heule wrote:

Shouldn't we use something other than the index for the OPC comment? I'm worried that this is going to cause problems when we change the table again in some way, and suddenly the indices mean different things depending on the version of x64asm. Couldn't we just use the Opcode string representation? It would have the advantage of being stable across different versions of x64asm as well as being readable by humans.

— Reply to this email directly or view it on GitHub https://github.com/StanfordPL/x64asm/issues/197#issuecomment-125963164.

stefanheule commented 9 years ago

Yeah, I know, this issue just brought it back into my mind, and I think we should fix it. We can do it here, or create a new ticket for it.

bchurchill commented 9 years ago

Here is fine. It's hardly any work for me to fix this.

On 07/29/2015 02:02 PM, Stefan Heule wrote:

Yeah, I know, this issue just brought it back into my mind, and I think we should fix it. We can do it here, or create a new ticket for it.

— Reply to this email directly or view it on GitHub https://github.com/StanfordPL/x64asm/issues/197#issuecomment-126094911.

bchurchill commented 9 years ago

Closed in 95ff3cdc7a97cc6