[Dwarf-Discuss] Section offset values
davea42 at earthlink.net
Mon Oct 25 09:54:38 PDT 2010
On 10/25/2010 05:31 AM, Jakub Křoustek wrote:
> I have an assembler/compiler related question about "section offset"
> attributes in DWARF, but I hope someone will be able to give me the answer.
> When I use some well known compiler like gcc, llvm-gcc or clang for
> assembler generation, I will get something like this:
> //target: linux x64
> //the same is for mips/x86/arm linux
> //gcc -g3 -S test.c
> .file "test.c"
> .section .debug_abbrev,"", at progbits
> .section .debug_info,"", at progbits
> .section .debug_pubnames,"", at progbits
> .long 0x35 //unit_length
> .value 0x2 //version
> .long .Ldebug_info0 //debug_info_offset<--- !!!
> As I read in the DWARF Debugging Standard, the ".long .Ldebug_info0"
> attribute in section .debug_pubnames means "The offset from the
> beginning of the .debug_info section ...". But the ".long" directive
> tells the assembler to store absolute address of the .Ldebug_info0 label
> (as is usual in most assemblers), not the section relative address,
> which will look like:
Check the .rel or .rela section!
When linking is later done the relocation
(which the compiler also creates) will have the right effect.
> .long .Ldebug_info0-.Ldebug_info0
> My question is: how will the assembler figure out that it must store an
> address from the beginning of a section and not an absolute address? The
> same situation is with debug_abbrev_offset in .debug_info section,
> debug_info_offset in .debug_pubtypes section, etc.
The compiler creates a relocation record. It's the relocation record
that results inthe value being fixed up when this object file is linked
with other object files. Any truly 'absolute' value would have
no relocation record pointing to it. Indeed,
would be wrong as that would normally generate an absolute value of zero
a value with a relocation.
A polar bear is a cartesian bear after a coordinate transform.
More information about the Dwarf-Discuss