4 ms·
Those are just ordinary relocations in PI code. You'll see this kind of information if you run, say, objdump -rd foo.o on a x86-64 object file that has been com
by gsg 12y ago
Those are just ordinary relocations in PI code. You'll see this kind of information if you run, say, objdump -rd foo.o on a x86-64 object file that has been compiled as PIC.
Note that your code fragment is not PIC, so it would not substitute in this situation.
- acqq 12y agoThanks. That explains me the part of "why." Still I believe even PIC is not written as the input for the assembler in that form? Then I can imagine a nicer objdump which would produce something more readable (or even immediately usable by the assembler).
- gsg 12y agoMore or less, yeah. You would still need to use RIP-relative addressing since that is how PIC functions, but you could have nice symbolic addresses. objdump is a very simple tool. If you want more featureful disassembly tools you should probably look at something like IDA.
- cnvogel 12y agoThe relocation mechanism is used for either pic or non-pic code. If parts of your code reside in different compilation units (.c files), there need to be a way to tell the linker how to jump from one to the other, even if the final program will be run at a well-known static position in the address space. Of course, when compiling -fpic versus -fno-pic, different types of relocation information will be produced, and the compiler might produce different instructions for branching. And unresolved symbols will remain in your library to be fixed up by the dynamic linker. But relocation entries will be produced for either case.
- gsg 12y agoI was referring to the PIC-specific 0x0(%rip) construct as well as the relocation. Sorry if that was unclear.