This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Who generate .rela.debug_info?
- From: Nancy <nancydreaming at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 19 Dec 2017 22:01:54 +0800
- Subject: Re: Who generate .rela.debug_info?
- Authentication-results: sourceware.org; auth=none
- References: <CADdyJmmV3ENy=8DnF4Abjn5KD7WU4hcsXM7tse4E1f7HF5JnUQ@mail.gmail.com> <alpine.LSU.2.21.1712181947280.25295@wotan.suse.de>
>> 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