search for: shf_merge

...to link this file using lld. It seems to be an uncommon case. To notify a user lld might show an error in that case. BTW it looks like there is another problem with relocation addend adjustment in case of relocatable object generation. I did not investigate it thoroughly though. Suppose we have a SHF_MERGE section with two "equal" entries and a relocation which points to the second entry using section+addend. Now we merge such sections even if we generate a relocatable object. In that case we write reduced SHF_MERGE section with the only entry. But the relocation still points to the removed...

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

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from, helping with debugging and analysis as required. Our proposal is to gi...

...kers. 1) 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 coalesc...

.../trunk/lib/Target/X86/X86MCInstLower.cpp : void X86AsmPrinter::EmitXRayTable() { if (Sleds.empty()) return; if (Subtarget->isTargetELF()) { auto *Section = OutContext.getELFSection( "xray_instr_map", ELF::SHT_PROGBITS, ELF::SHF_ALLOC | ELF::SHF_GROUP | ELF::SHF_MERGE, 0, CurrentFnSym->getName()); auto PrevSection = OutStreamer->getCurrentSectionOnly(); OutStreamer->SwitchSection(Section); for (const auto &Sled : Sleds) { OutStreamer->EmitSymbolValue(Sled.Sled, 8); OutStreamer->EmitSymbolValue(CurrentFnSym, 8);...

...n mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file and the > print-gc/icf-sections output. This extension would be to report the pieces > of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or > at least the majority) of the contents of these sections in the output come > from inputs, it would be beneficial in trying to associate the output > contents with where they came from, helping with debugging and analysis as > required. O...

...elocation approach: 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 i...

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

...nd that we 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...

...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 "c...

With the MIPS compiler, when we have static constants, in the .s file we get something like: .type $.str33, at object # @.str33 .section .rodata.str1.1,"aMS", at progbits,1 $.str33: .asciz "//" .size $.str33, 3 Currently when we create direct object code we are referencing the symbol as an offset in .rodata and not directly using

....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. This is a problem only if the .debug_str section *by itself* exceeds 4GB; are we ant...

..." 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 >&gt...

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

...<class ELFT> void LinkerDriver::link(opt::InputArgList &Args) { if (!Config->Relocatable) InputSections.push_back(createCommentSection()); - // Replace common symbols with regular symbols. - replaceCommonSymbols(); // Do size optimizations: garbage collection, merging of SHF_MERGE sections On Fri, Jun 21, 2019 at 8:39 PM Rui Ueyama <ruiu at google.com> wrote: > Let me investigate. > > On Fri, Jun 21, 2019 at 5:08 PM Mani, Suresh <Suresh.Mani at amd.com> wrote: > >> Thanks for the info Teresa, >> >> >> >> Regards >&gt...

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

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

...rce 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 e...

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

> On 4 Aug 2016, at 06:27, Serge Rogatch <serge.rogatch at gmail.com> wrote: > > Hi Dean, > > I have a question about the following piece of code in compiler-rt/trunk/lib/xray/xray_trampoline_x86.S : > movq _ZN6__xray19XRayPatchedFunctionE(%rip), %rax > testq %rax, %rax > je .Ltmp0 > > // assume that %r10d has the function id. > movl %r10d,