Who generate .rela.debug_info?

Who generate .rela.debug_info?

[Nancy]

Dear list，

tls.c:
__thread int i=10;

$gcc -g -c -save-temps tls.c
$readelf -r tls.o
Relocation section '.rela.debug_info' at offset 0x2d0 contains 6 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000006  00070000000a R_X86_64_32       0000000000000000 .debug_abbrev + 0
00000000000c  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 11
000000000011  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 3f
000000000015  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 0
000000000019  00090000000a R_X86_64_32       0000000000000000 .debug_line + 0
000000000028  000d00000015 R_X86_64_DTPOFF32 0000000000000000 i + 0

Relocation section '.rela.debug_aranges' at offset 0x360 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000006  00060000000a R_X86_64_32       0000000000000000 .debug_info + 0

I can't find any code in cc1 or as that generate R_X86_64_DTPOFF32 in
.rela.debug_info section. Did I miss something?


-- 
Best Regards,
Yu Rong Tan

Re: Who generate .rela.debug_info?

[Nathan Sidwell]

On 12/18/2017 08:57 AM, Nancy wrote:
> Dear list，
> 
> tls.c:
> __thread int i=10;
> 
> $gcc -g -c -save-temps tls.c
> $readelf -r tls.o
> Relocation section '.rela.debug_info' at offset 0x2d0 contains 6 entries:

> Relocation section '.rela.debug_aranges' at offset 0x360 contains 1 entries:
>    Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000006  00060000000a R_X86_64_32       0000000000000000 .debug_info + 0
> 
> I can't find any code in cc1 or as that generate R_X86_64_DTPOFF32 in
> .rela.debug_info section. Did I miss something?

.rela.X is a relocation section generated by the assembler.  GCC emits 
debug information using assembler pseudos such as .word etc.  Those will 
name relocations.  The syntax for relocations is target-specific.  The 
above will be some_symbol@dtpoff or something.

nathan

-- 
Nathan Sidwell

Re: Who generate .rela.debug_info?

[Nancy]

> .rela.X is a relocation section generated by the assembler.  GCC emits debug
> information using assembler pseudos such as .word etc.  Those will name
> relocations.  The syntax for relocations is target-specific.  The above will
> be some_symbol@dtpoff or something.

Sorry, I did not find it in "AS". I did saw .text .data  .bss and some
other new segment created by "AS" through function "subseg_new", but I
could not find out where and how ".rela.debug_info" is generated. For
this case, "as" dwarf2dbg.c(binutils-2.29.1): 1932
if(emit_other_sections) does not run (emit_other_section==0).

My understand, all .debug_XXX is generated by GCC, "AS" just copy them
to obj, not a bit change. But I also could not find ".rela.X" in GCC.

Did I miss something?  I need a breakpoint to see "Oh it really
created it there~"

-- 
Best Regards,
Yu Rong Tan

Re: Who generate .rela.debug_info?

[Andreas Schwab]

See bfd/elflink.c, everything related to dynamic reloc sections.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Who generate .rela.debug_info?

[Nathan Sidwell]

On 12/19/2017 08:53 AM, Nancy wrote:
>> .rela.X is a relocation section generated by the assembler.  GCC emits debug
>> information using assembler pseudos such as .word etc.  Those will name
>> relocations.  The syntax for relocations is target-specific.  The above will
>> be some_symbol@dtpoff or something.
> 
> Sorry, I did not find it in "AS". I did saw .text .data  .bss and some
> other new segment created by "AS" through function "subseg_new", but I
> could not find out where and how ".rela.debug_info" is generated. For
> this case, "as" dwarf2dbg.c(binutils-2.29.1): 1932
> if(emit_other_sections) does not run (emit_other_section==0).
> 
> My understand, all .debug_XXX is generated by GCC, "AS" just copy them
> to obj, not a bit change. But I also could not find ".rela.X" in GCC.

That is correct.  GCC emits an ascii text representation that the 
assembler converts to a binary ELF representation.  ELF represents a 
what one thinks of as a single section as two sections.  One with the 
regular name given it -- '.debug_info' or whatever.  This holds the 
binary image of that section.  The other section is named '.rela<NAME>' 
(or .rel<NAME>' depending on the target ABI) to hold the relocation 
data.  This is handled by the assembler & BFD.

It's not clear to my why you want this level of detail -- curiosity?

http://www.sco.com/developers/gabi/latest/contents.html
https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf


nathan

-- 
Nathan Sidwell

Re: Who generate .rela.debug_info?

[Nancy]

> It's not clear to my why you want this level of detail -- curiosity?
I need to enable this feature on open64.

Thank you all for your great infos.

-- 
Best Regards,
Yu Rong Tan

Re: Who generate .rela.debug_info?

[Michael Matz]

Hi,

On Mon, 18 Dec 2017, Nancy wrote:

> tls.c:
> __thread int i=10;
> 
> $gcc -g -c -save-temps tls.c
> $readelf -r tls.o
> Relocation section '.rela.debug_info' at offset 0x2d0 contains 6 entries:
>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000006  00070000000a R_X86_64_32       0000000000000000 .debug_abbrev + 0
> 00000000000c  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 11
> 000000000011  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 3f
> 000000000015  000a0000000a R_X86_64_32       0000000000000000 .debug_str + 0
> 000000000019  00090000000a R_X86_64_32       0000000000000000 .debug_line + 0
> 000000000028  000d00000015 R_X86_64_DTPOFF32 0000000000000000 i + 0
> 
> Relocation section '.rela.debug_aranges' at offset 0x360 contains 1 entries:
>   Offset          Info           Type           Sym. Value    Sym. Name + Addend
> 000000000006  00060000000a R_X86_64_32       0000000000000000 .debug_info + 0
> 
> I can't find any code in cc1 or as that generate R_X86_64_DTPOFF32 in
> .rela.debug_info section. Did I miss something?

To expand on what Nathan said: the debug info needs to refer to the 
location of the variable 'i' somehow, and as it's a TLS variable that 
location is thread specific as well, and so the normal data relocations 
can't be used.  So the dwarf info contains a location expression that uses 
this relocation and a GNU extension to push the tls address into the 
expression stack.  See e.g. the verbose asm output for the above file, the 
DIE for 'i' will contain something like this:

        .uleb128 0x2    # (DIE (0x1d) DW_TAG_variable)
        .ascii "i\0"    # DW_AT_name
        .byte   0x1     # DW_AT_decl_file (x.c)
        .byte   0x1     # DW_AT_decl_line
        .long   0x31    # DW_AT_type
                        # DW_AT_external
        .uleb128 0xa    # DW_AT_location
        .byte   0xe     # DW_OP_const8u
        .long   i@dtpoff, 0
        .byte   0xe0    # DW_OP_GNU_push_tls_address

The 'i@dtpoff' is the field that causes the DTPOFF32 relocation to be 
created by the assembler.


Ciao,
Michael.

Re: Who generate .rela.debug_info?

[Nancy]

>> I can't find any code in cc1 or as that generate R_X86_64_DTPOFF32 in
>> .rela.debug_info section. Did I miss something?
>
> To expand on what Nathan said: the debug info needs to refer to the
> location of the variable 'i' somehow, and as it's a TLS variable that
> location is thread specific as well, and so the normal data relocations
> can't be used.  So the dwarf info contains a location expression that uses
> this relocation and a GNU extension to push the tls address into the
> expression stack.  See e.g. the verbose asm output for the above file, the
> DIE for 'i' will contain something like this:
>
>         .uleb128 0x2    # (DIE (0x1d) DW_TAG_variable)
>         .ascii "i\0"    # DW_AT_name
>         .byte   0x1     # DW_AT_decl_file (x.c)
>         .byte   0x1     # DW_AT_decl_line
>         .long   0x31    # DW_AT_type
>                         # DW_AT_external
>         .uleb128 0xa    # DW_AT_location
>         .byte   0xe     # DW_OP_const8u
>         .long   i@dtpoff, 0
>         .byte   0xe0    # DW_OP_GNU_push_tls_address
>
> The 'i@dtpoff' is the field that causes the DTPOFF32 relocation to be
> created by the assembler.

My understand, .debug_info is generated by compiler, and that is quite
format, DIE entry, TAG, Attributes
<c1>   DW_AT_location    : 10 byte block: e 0 0 0 0 0 0 0 0 e0
(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

How ".long   i@dtpoff, 0" generated in .debug_info???  I mean that is
not that format. How it stored in DIE format?  Do you mean it not in
DIE entry, but in ASM pass adds ".long   i@dtpoff, 0" to .s, only
store in .s?

-- 
Best Regards,
Yu Rong Tan