* Who generate .rela.debug_info?
@ 2017-12-18 13:57 Nancy
2017-12-18 14:12 ` Nathan Sidwell
2017-12-18 18:50 ` Michael Matz
0 siblings, 2 replies; 8+ messages in thread
From: Nancy @ 2017-12-18 13:57 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-18 13:57 Who generate .rela.debug_info? Nancy
@ 2017-12-18 14:12 ` Nathan Sidwell
2017-12-19 13:53 ` Nancy
2017-12-18 18:50 ` Michael Matz
1 sibling, 1 reply; 8+ messages in thread
From: Nathan Sidwell @ 2017-12-18 14:12 UTC (permalink / raw)
To: Nancy, gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-18 13:57 Who generate .rela.debug_info? Nancy
2017-12-18 14:12 ` Nathan Sidwell
@ 2017-12-18 18:50 ` Michael Matz
2017-12-19 14:01 ` Nancy
1 sibling, 1 reply; 8+ messages in thread
From: Michael Matz @ 2017-12-18 18:50 UTC (permalink / raw)
To: Nancy; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-18 14:12 ` Nathan Sidwell
@ 2017-12-19 13:53 ` Nancy
2017-12-19 13:59 ` Andreas Schwab
2017-12-19 14:03 ` Nathan Sidwell
0 siblings, 2 replies; 8+ messages in thread
From: Nancy @ 2017-12-19 13:53 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: gcc
> .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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-19 13:53 ` Nancy
@ 2017-12-19 13:59 ` Andreas Schwab
2017-12-19 14:03 ` Nathan Sidwell
1 sibling, 0 replies; 8+ messages in thread
From: Andreas Schwab @ 2017-12-19 13:59 UTC (permalink / raw)
To: Nancy; +Cc: Nathan Sidwell, gcc
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-18 18:50 ` Michael Matz
@ 2017-12-19 14:01 ` Nancy
0 siblings, 0 replies; 8+ messages in thread
From: Nancy @ 2017-12-19 14:01 UTC (permalink / raw)
To: Michael Matz; +Cc: gcc
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-19 13:53 ` Nancy
2017-12-19 13:59 ` Andreas Schwab
@ 2017-12-19 14:03 ` Nathan Sidwell
2017-12-21 11:27 ` Nancy
1 sibling, 1 reply; 8+ messages in thread
From: Nathan Sidwell @ 2017-12-19 14:03 UTC (permalink / raw)
To: Nancy; +Cc: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Who generate .rela.debug_info?
2017-12-19 14:03 ` Nathan Sidwell
@ 2017-12-21 11:27 ` Nancy
0 siblings, 0 replies; 8+ messages in thread
From: Nancy @ 2017-12-21 11:27 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-21 11:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-18 13:57 Who generate .rela.debug_info? Nancy
2017-12-18 14:12 ` Nathan Sidwell
2017-12-19 13:53 ` Nancy
2017-12-19 13:59 ` Andreas Schwab
2017-12-19 14:03 ` Nathan Sidwell
2017-12-21 11:27 ` Nancy
2017-12-18 18:50 ` Michael Matz
2017-12-19 14:01 ` Nancy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).