search for: sht_rel

...h "Relocation Section" entries. But I think this solution is a little bit over designed. Any objections / suggestions? [[ Sections: - Name: .text Type: SHT_PROGBITS Content: "0000000000000000" AddressAlign: 16 Flags: [SHF_ALLOC] - Name: .rel.text Type: SHT_REL Info: .text AddressAlign: 4 Relocations: - !Relocation Offset: 0x1 SymbolName: glob1 Type: R_MIPS_32 - !Relocation Offset: 0x2 SymbolName: glob2 Type: R_MIPS_CALL16 ]] -- Simon Atanasyan

...link time. GCC also generated zero for stmt_list in the objects but links correctly in the end. I still haven't figured out which type of relocation is needed. All I know is that GCC generates .rel.debug_info relocations that clang doesn't: clang: ** Section #6 '.rel.debug_info' (SHT_REL) Size : 40 bytes (alignment 4) Symbol table #22 '.symtab' 5 relocations applied to section #5 '.debug_info' GCC: ** Section #7 '.rel.debug_info' (SHT_REL) Size : 184 bytes (alignment 4) Symbol table #22 '.symtab' 23 relocations applied t...

...ctions / suggestions? > > > > [[ > > Sections: > > - Name: .text > > Type: SHT_PROGBITS > > Content: "0000000000000000" > > AddressAlign: 16 > > Flags: [SHF_ALLOC] > > > > - Name: .rel.text > > Type: SHT_REL > > Info: .text > > AddressAlign: 4 > > Relocations: > > - !Relocation > > Offset: 0x1 > > SymbolName: glob1 > > Type: R_MIPS_32 > > - !Relocation > > Offset: 0x2 > > SymbolNa...

See "DwarfDebug problem with line section" thread on llvmdev. Bottom line, we may need a target specific patch for targets that do not follow dwarf standard (as per my reading) in this particular case. - Devang On Wed, Aug 25, 2010 at 5:49 AM, Renato Golin <rengolin at systemcall.org>wrote: > Hi, > > I'm trying to compile two files together with debug information

...t_list in the objects but links correctly in the > end. > > I still haven't figured out which type of relocation is needed. All I > know is that GCC generates .rel.debug_info relocations that clang > doesn't: > > clang: > > ** Section #6 '.rel.debug_info' (SHT_REL) > Size : 40 bytes (alignment 4) > Symbol table #22 '.symtab' > 5 relocations applied to section #5 '.debug_info' > > GCC: > > ** Section #7 '.rel.debug_info' (SHT_REL) > Size : 184 bytes (alignment 4) > Symbol table #22 '.sy...

Hi, I'm trying to compile two files together with debug information but seems that LLVM is getting the DW_AT_stmt_list wrong when ld is linking the final executable. Originally, I tried on ARM with Clang (+llc+gas+ln) and, the object files, the DW_AT_stmt_list were null, as expected. When linking, they should point to the offset in the line table, but all of them are still null, so pointing

Hi, As far as I understand now it is impossible to generate ELF object file with relocation sections using yaml2obj tool. I plan to support ELF relocations in the yaml2obj. Does anybody work on it already or plan to start this task soon? -- Simon Atanasyan

...ng sections live to the following loop: for (InputSectionBase *Sec : InputSections) {     if (Sec->Flags & SHF_LINK_ORDER)         Sec->Live = Sec->getLinkOrderDep()->Live;     else {         bool IsAlloc = (Sec->Flags & SHF_ALLOC);         bool IsRel = (Sec->Type == SHT_REL || Sec->Type == SHT_RELA);         if (!IsAlloc && !IsRel)         Sec->Live = true;     } } If an input section has the SHF_LINK_ORDER flag set, it propagates the liveness of this section to the parent. This allows the garbage collector to also remove children sections if depen...

...owing loop: > >for (InputSectionBase *Sec : InputSections) { > if (Sec->Flags & SHF_LINK_ORDER) > Sec->Live = Sec->getLinkOrderDep()->Live; > else { > bool IsAlloc = (Sec->Flags & SHF_ALLOC); > bool IsRel = (Sec->Type == SHT_REL || Sec->Type == SHT_RELA); > if (!IsAlloc && !IsRel) > Sec->Live = true; > } >} > >If an input section has the SHF_LINK_ORDER flag set, it propagates the >liveness >of this section to the parent. This allows the garbage collector to also &gt...

...Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer the relocation based approach: if a .debug_* has an 64-bit absolute relocation type (e.g. R_X86_64_64). In LLD, for an input section, we don't know its associated SHT_REL[A] section. So when adding an orphan section we would have another loop iterating over inputSections. We can reuse the dependentSections to have this piece of information (generalizing the existing special case for -r/--emit-relocs) > This way as long as DWARF32 sections don't themselves go...

...where) >or Sony (-2 in debug_ranges, -1 elsewhere)... - so, wouldn't actually work >for any producer currently, so maybe there's little value in that as a >feature)) For a non-SHF_ALLOC section, LLD currently considers it a GC root if all the conditions below are satisfied: * not SHT_REL[A] * not SHF_LINK_ORDER * not in a section group (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35 onwards will have mostly compatible semantics with LLD) There is a cost fragmenting a .debug_* section: sizeof(Elf64_Shdr)=64 -> each section takes 64 bytes in the section header...

...d Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer the relocation based approach: if a .debug_* has an 64-bit absolute relocation type (e.g. R_X86_64_64). In LLD, for an input section, we don't know its associated SHT_REL[A] section. So when adding an orphan section we would have another loop iterating over inputSections. We can reuse the dependentSections to have this piece of information (generalizing the existing special case for -r/--emit-relocs) > This way as long as DWARF32 sections don't themselves go...

...tually > > work > > >for any producer currently, so maybe there's little value in that as a > > >feature)) > > > > For a non-SHF_ALLOC section, LLD currently considers it a GC root if all > > the conditions below are satisfied: > > > > * not SHT_REL[A] > > * not SHF_LINK_ORDER > > * not in a section group > > > > (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35 > > onwards will have mostly compatible semantics with LLD) > > > > There is a cost fragmenting a .debug_* section: sizeof(El...

...39;s little value in that as > > a > > > > >feature)) > > > > > > > > For a non-SHF_ALLOC section, LLD currently considers it a GC root if > > all > > > > the conditions below are satisfied: > > > > > > > > * not SHT_REL[A] > > > > * not SHF_LINK_ORDER > > > > * not in a section group > > > > > > > > (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35 > > > > onwards will have mostly compatible semantics with LLD) > > > > > &g...

...; > >feature)) > >> > > > > >> > > > For a non-SHF_ALLOC section, LLD currently considers it a GC root if > >> > all > >> > > > the conditions below are satisfied: > >> > > > > >> > > > * not SHT_REL[A] > >> > > > * not SHF_LINK_ORDER > >> > > > * not in a section group > >> > > > > >> > > > (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35 > >> > > > onwards will have mostly compatible se...

...like from your proposal that your linker keeps the “compact unwind group description” records as is and just concatenates them, and the runtime would need to understand the prolog/epilog encoding. I would think that just widening the group record (as you suggest in 5.1) would be much simpler (like SHT_REL was widened to SHT_RELA). -Nick > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is our proposal to extend/enhance the x86-64 compact unwind > descriptors to fully describe the prologue/epilogue for asynchronous > unwindi...

...sal that your linker keeps the “compact > unwind group description” records as is and just concatenates them, and the > runtime would need to understand the prolog/epilog encoding. I would think > that just widening the group record (as you suggest in 5.1) would be much > simpler (like SHT_REL was widened to SHT_RELA). > > -Nick > > > > > On Jan 26, 2018, at 7:54 AM, John Reagan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Here is our proposal to extend/enhance the x86-64 compact unwind > > descriptors to fully describe the p...

...> > >> >> > > > For a non-SHF_ALLOC section, LLD currently considers it a GC root if > >> >> > all > >> >> > > > the conditions below are satisfied: > >> >> > > > > >> >> > > > * not SHT_REL[A] > >> >> > > > * not SHF_LINK_ORDER > >> >> > > > * not in a section group > >> >> > > > > >> >> > > > (I managed to lobby the ideas to GNU ld. GNU ld from binutils 2.35 > >> >> > &gt...

As has been mentioned elsewhere, Sony generally fixes up references from debug info to stripped functions (of any length) using -1, because that's a less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base address for shared libraries, I'd think using it has the potential to mislead various consumers.) For .debug_ranges we use -2, because both a 0/0 pair and a -1/-1 pair

At Sony we offer autolinking as a feature in our ELF toolchain. We would like to see full support for this feature upstream as there is anecdotal evidence that it would find use beyond Sony. In general autolinking (https://en.wikipedia.org/wiki/Auto-linking) allows developers to specify inputs to the linker in their source code. LLVM and Clang already have support for autolinking on ELF via