Why does asm("mov 0x12345678, %ax") cause a seg fault?

[mynameisflorian]

Why does asm("mov 0x12345678, %ax") cause a seg fault?

I'm tinkering with assembly and can't understand why this is happening. I hope someone can explain it for me.

I have a simple c++ program. I added a line with asm("mov 0x12345678, %ax") so I can find that part in the assembly code.

If I compile then run it with gdb, it encounters a seg fault at XYZ. If I "objdump -d a.out > out.s" and look for XYZ -- guess what? that's the line where my mov statement is, not after. I don't think the following instruction would be affected by this ("movq -32(%rbp), %rax"), but it's not faulting on that line, it's faulting on the 0x12345678 line. I've tried %rax, %eax, %bx, %rbx, etc -- all fault. BTW, this is a 64-bit linux target...

Any Ideas?

- Florian

[TkTech]

A. You need to prefix literal values with '$'. You aren't trying to move 0x12345678 into %ax, you're moving 16bits from the address 0x12345678 into %ax. Hello, seg fault.

B. $0x12345678 is a 32bit value. You're trying to move it into a 16bit register, %ax.

[mynameisflorian]

A) uh ... duh ... thanks!

B) sorry, I started off with %eax. %ax must've snuck in there during the "try random stuff until it works" phase (that's the one right before I give up and ask for help)

Again, thanks for your help!

- Florian

[foxmuldr]

Non-Intel syntax always confuses me.

BTW, if you're looking for a way to inject assembly code into your program, you can use "asm("int 3")" and "asm("nop")" as one-byte opcodes which will cause a break in your program in all conditions, and can then be replaced with edit-and-continue (or by writing the byte 0x90 to the memory address) to the NOP version, which doesn't do anything, but is simply an opcode placeholder. Many debuggers do this.

The int 3 opcode can be either 0xcc, or 0xcd, 0x03, and both work identically, it's just that one of them is one-byte, the other is two.

- Rick