search for: shf_strings

...emoved second entry and in fact points out of the section border. Please correct me if I miss something. I think we can fix that by the following way: 1. Do not try to merge SHF_MERGE sections if Config->Relocatable is true. 2. Do not group such sections together or group sections with the same SHF_STRINGS / sh_entsize parameters. 3. Keep SHF_STRINGS flag and sh_entsize value when writing the sections. In that case a linker will be able to merge/reduce such sections later when it links a relocatable object to get DSO or executable file. On Wed, Sep 28, 2016 at 11:41 PM, Rui Ueyama <ruiu at google...

...lly getting slower over time in general. - There are a few commits that increased link time by a few percent or more. - However, we also committed a few performance improvement changes to offset them. The commit that increased link time most (+15%) is r251212: Add support for merging string from SHF_STRINGS sections. This does not come as a surprise since string merging is a computationally heavy operation. The commit that decreased link time most (-29%) is r250315: ELF2: Merge .{text,rodata,data,bss}.* sections. This is because the commit significantly decreased number of sections in the output. Th...

...Ordering/Grouping atoms when we write to the output file will become easier 2) When we add linker script support, it clearly maps into this usecase >> 3) Certain things w.r.t the ELF file is not completely represented by Atoms >> a) Merging constants in the sections have SHF_MERGE/SHF_STRINGS flag set > This idea for SHF_MERGE/SHF_STRINGS sections is that the content is broken upon into atoms based on the sh_entsize value. The atoms have a merge type of mergeByConent (which seems to be currently missing from DefinedAtom.h). The core linking part of lld knows to coalesce atoms that...

You are right. LLD does not have this problem. Initially I bumped into the MIPS specific bug related to GP relative relocations calculation. I tried to make reproduction script as general as possible and mistakenly make it too general. So now with your help I realized that the problem solely affects MIPS. On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org> wrote: >

...when we write .debug_str 0 : { *(.debug_str) }, we really want the output section .debug_str can be made up with just information from the input section descriptions, not random information from other .debug_* LLD -O1 (default) and GNU ld -O0 enable constant string merge within SHF_MERGE&&SHF_STRINGS sections. We need to pay attention as if a DWARF32 string gets folded into a DWARF64 string, the section referencing the DWARF32 string can still trigger a relocation overflow. If we order DWARF32 components before DWARF64 components, with the llvm::StringTableBuilder usage in LLD, we can make su...

...divorce the implementation from the idea of "linker options" which, by nature, would tie source code to the vagaries of particular linkers. I don't see much value in supporting other linker operations so I suggest that the binary representation be a mergable string section (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the output). The compiler can form this section by concatenating the arguments of the "comment lib" pragmas in the order they are encountered. Partial (-r, -Ur) lin...

....debug_str) }, we really want > the > output section .debug_str can be made up with just information from the > input > section descriptions, not random information from other .debug_* > > LLD -O1 (default) and GNU ld -O0 enable constant string merge within > SHF_MERGE&&SHF_STRINGS sections. We need to pay attention as if a DWARF32 > string gets folded into a DWARF64 string, the section referencing the > DWARF32 > string can still trigger a relocation overflow. This is a problem only if the .debug_str section *by itself* exceeds 4GB; are we anticipating that will h...

...tation from the idea of "linker options" which, > by nature, would tie source code to the vagaries of particular linkers. I > don't see much value in supporting other linker operations so I suggest > that the binary representation be a mergable string section (SHF_MERGE, > SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK > (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the > output). The compiler can form this section by concatenating the arguments > of the "comment lib" pragmas in the order they are encountered. Partia...

...idea of "linker options" which, by >> nature, would tie source code to the vagaries of particular linkers. I >> don't see much value in supporting other linker operations so I suggest >> that the binary representation be a mergable string section (SHF_MERGE, >> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >> output). The compiler can form this section by concatenating the arguments >> of the "comment lib" pragmas in the order they are encount...

...idea of "linker options" which, by >> nature, would tie source code to the vagaries of particular linkers. I >> don't see much value in supporting other linker operations so I suggest >> that the binary representation be a mergable string section (SHF_MERGE, >> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >> output). The compiler can form this section by concatenating the arguments >> of the "comment lib" pragmas in the order they are encount...

...t; which, >>>> by nature, would tie source code to the vagaries of particular linkers. I >>>> don't see much value in supporting other linker operations so I suggest >>>> that the binary representation be a mergable string section (SHF_MERGE, >>>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>>> output). The compiler can form this section by concatenating the arguments >>>> of the "comment lib" pragmas in th...

...t; by nature, would tie source code to the vagaries of particular linkers. I >>>>>> don't see much value in supporting other linker operations so I suggest >>>>>> that the binary representation be a mergable string section (SHF_MERGE, >>>>>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>>>>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>>>>> output). The compiler can form this section by concatenating the arguments >>>>>> of the "comment...

...nker options" which, >>> by nature, would tie source code to the vagaries of particular linkers. I >>> don't see much value in supporting other linker operations so I suggest >>> that the binary representation be a mergable string section (SHF_MERGE, >>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>> output). The compiler can form this section by concatenating the arguments >>> of the "comment lib" pragmas in the order they...

...source code to the vagaries of particular >>>>>>>> linkers. I don't see much value in supporting other linker operations so I >>>>>>>> suggest that the binary representation be a mergable string section >>>>>>>> (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type >>>>>>>> SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents >>>>>>>> appearing in the output). The compiler can form this section by >>>>>>>> concatenating the argume...

...source code to the vagaries of particular >>>>>>>> linkers. I don't see much value in supporting other linker operations so I >>>>>>>> suggest that the binary representation be a mergable string section >>>>>>>> (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type >>>>>>>> SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents >>>>>>>> appearing in the output). The compiler can form this section by >>>>>>>> concatenating the argume...

...t;>>> by nature, would tie source code to the vagaries of particular linkers. I >>>>> don't see much value in supporting other linker operations so I suggest >>>>> that the binary representation be a mergable string section (SHF_MERGE, >>>>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>>>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>>>> output). The compiler can form this section by concatenating the arguments >>>>> of the "comment lib" p...

...ies of particular >>>>>>>>>> linkers. I don't see much value in supporting other linker operations so I >>>>>>>>>> suggest that the binary representation be a mergable string section >>>>>>>>>> (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type >>>>>>>>>> SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents >>>>>>>>>> appearing in the output). The compiler can form this section by >>>>>>>>>>...

...gt;>>>>>>> particular linkers. I don't see much value in supporting other linker >>>>>>>>>>>> operations so I suggest that the binary representation be a mergable string >>>>>>>>>>>> section (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type >>>>>>>>>>>> SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents >>>>>>>>>>>> appearing in the output). The compiler can form this section by >>>>>>&...

You should probably pull in some folks who implemented/maintain the feature for Darwin. I guess they aren't linking this info, but only communicating in the object file between tools - maybe they flag these sections (either in the object, or by the linker) as ignored/dropped during linking. That semantic could be implemented in ELF too by marking the sections SHF_IGNORED or something

"On Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul