>> 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
