0

For an assignment, I have the following code:

.global _start

.section .data
arr: .short 1, 2, 3, 4, 5
b: .quad 0x1234567890123456

.section .text
_start:
    movq $arr, b

We are to assume that the address of the arr label is 0xDEADBEEF, and decide if the command is legal.

Looking through the Intel manual, I found that movq takes a 32-bit number and sign-extends it into the 64-bit memory location (b in this case).
When assembling and running the code locally (using as and gdb), everything seems to work fine, but the address of arr is 0x402000, and not 0xDEADBEEF. So I tried running:

movq $0xDEADBEEF, b

but the assembly failed with:

Error: operand type mismatch for `movq'

which is confusing, as 0xDEADBEEF is 32-bit literal.
So my two questions are:

  1. Why does the above command not work (I assume it has something to do with the sign extension)?
  2. If the address of arr was 0xDEADBEEF, would the assembler fail as well?
Eran Cohen
  • 1
  • 1
  • 1
  • `0x00000000DEADBEEF` can't be represented as a 32-bit *sign*-extended integer. 2. Yes, you'd get a link error about a failed relocation, similar to what you'd get if you tried to link your `.o` into a shared library or PIE executable (`gcc -pie -nostdlib foo.o`) – Peter Cordes Apr 04 '22 at 06:48
  • For 2, the assembler itself wouldn't fail, just linking. The result would be just like if you had some really large arrays that pushed the address outside the low 2GiB. (Or 4GiB depending on how the compiler used it): [What does this GCC error "... relocation truncated to fit..." mean?](https://stackoverflow.com/a/47168086) – Peter Cordes Apr 04 '22 at 07:07
  • I knew there was a duplicate somewhere about values that fit in 32-bit zero-extended but not 32-bit sign-extended. Finally looked carefully at Margaret Bloom's answer on [What's the difference between the x86-64 AT&T instructions movq and movabsq?](https://stackoverflow.com/q/52434073) and realized that was it! – Peter Cordes Apr 04 '22 at 07:11
  • Ah, I think I understand now, thank you! Is there a way to ask the linker to give a specific address to a label? It would be nice to see this behavior in action. – Eran Cohen Apr 04 '22 at 08:10
  • With a linker script, sure, or `ld -Tdata=0xdeadbeef` to start the `.data` section there, I think. Or just make some huge objects in `.bss` so the current position gets above 2GiB (but still below 4GiB), like suggested in [What does this GCC error "... relocation truncated to fit..." mean?](https://stackoverflow.com/a/47168086) – Peter Cordes Apr 04 '22 at 08:16

0 Answers0