> "q" means "qword", i. e. it's a 64-bit operation. On my system objdump
(binutils-2.36.1) just print "call" instead of "callq", because there is
no "calll" ("32-bit call") operation in a 64-bit x86 program.
So whenever I see instructions end with q, I should trim it off and
look it up in the intel manual. This part is confusing.
> You can see the hexdump is E8 00 00 00 00. It's clearly documented at
> page 3-122:
>
>> E8 cd:
>>
>> CALL rel32
>>
>> near, relative, displacement relative to next
>> instruction. 32-bit displacement sign extended to
>> 64-bits in 64-bit mode.
What is "cd"?
How come "E8 cw" is mentioned with "N.S" in the manual? If it is not
supported, why mention it in the manual?
>> https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
>>
>> > > $ objdump --disassemble=main a.out
>> > > ...
>> > > 0000000000001135 <main>:
>> > > 1135: 55 push %rbp
>> > > 1136: 48 89 e5 mov %rsp,%rbp
>> > > 1139: 48 8d 3d c4 0e 00 00 lea
>> > > 0xec4(%rip),%rdi #
>> > > 2004
>> > > <_IO_stdin_used+0x4>
>> > > 1140: e8 eb fe ff ff callq 1030 <puts@plt>
>> > > 1145: b8 00 00 00 00 mov $0x0,%eax
>> > > 114a: 5d pop %rbp
>> > > 114b: c3 retq
>> > > ...
>> > >
>> > > How does objdump figure out 0xec4(%rip) is the address
>> > > _IO_stdin_used+0x4?
>> >
>> > I guess it just picks the closest symbol. It's basically meaningless
>> > in this case.
>>
>> Are you sure it is nonsense? If it is nonsense, why is it generated?
>> _IO_stdin_used is clearly a symbol in the .rodata section.
>>
>> $ readelf -s a.out | grep _IO_stdin_used
>> 55: 0000000000002000 4 OBJECT GLOBAL DEFAULT 16
>> _IO_stdin_used
>> $ readelf -SW a.out | grep '\[16\]'
>> [16] .rodata PROGBITS 0000000000002000 002000
>> 000011 00 A 0 0 4
>>
>
> In a specific binary it may make some sense: +0x4 is just calculated as
> a offset related to the nearest symbol ("_IO_stdin_used" here).
> Generally it's nonsense: the compiler and linker may reorder objects,
> there is no way to predict the location of an object (unless using some
> tricky linker scripts).
> 0xec4(%rip) means "the value of %rip (the program counter) plus 0xec4",
i. e. (the location of <main>) + (the offset of the next instruction in
<main>) + 0xec4. It's somewhere in .rodata, and the nearest symbol
before it is _IO_stdin_used. Then just a substraction can get 0x4.
I understand what it means. But my question is what raw-data fields in
the ELF file is used to figure this out the address is 0xec4 relative
to the current instruction? My question is not about how to interpret
what `0xec4(%rip)` means.
--
Regards,
Peng
