In this case your addresses are absolute because you have a position-dependent executable (not a PIE). There's a field in the ELF metadata (set by the linker) that specifies what virtual address to map the executable. You can use readelf -a
to see that and much more.
In a PIE executable the hex addresses would be relative to the "image base", which normally means relative to the start of the file. (Similar to a .o
, where the addresses count from 0
at the start of the .text
section). You can use --adjust-vma=offset
to set a base address for printing those addresses.
Yes, column 2 is a hexdump of the machine code, as single bytes in memory order. Objdump isn't interpreting them as little-endian-words or anything like that, just a pair of hex digits per byte, in order of increasing address.
x86 machine code is basically a byte-stream. Instructions are composed of
[prefixes] opcode [modrm [SIB] displacement0/8/32] [immediate8/32]
The opcode is either a single byte, or a sequence of bytes specified in memory order in Intel / AMD's documentation, e.g. 0F AF /r
for imul reg, reg/mem
Some instructions have 16-bit immediates, but normally it's 1 or 4 bytes if present at all.
Endianness is only relevant for multi-byte displacements in addressing modes, or multi-byte immediates.
e.g. mov $0x12345678, %eax
in foo.s
, assembles with gcc -c foo.s
to a .o
that disassembles as:
0: b8 78 56 34 12 mov $0x12345678,%eax
See also more links to x86 docs / manuals in SO's x86 tag wiki, including Intel's PDF manuals
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…