search for: shf_link_order

>Hi folks, > >Our LLVM compiler creates a special debug section, which depends on a >certain >text section. This debug section is created with the SHF_LINK_ORDER >flag, and >sh_link field in the section header points to the correct section. > >When linking the program with the linker flag '-gc-sections', lld can >garbage- >collect unused sections. In my case, the text section is correctly garbage- >collected. However, the linke...

Hi folks, Our LLVM compiler creates a special debug section, which depends on a certain text section. This debug section is created with the SHF_LINK_ORDER flag, and sh_link field in the section header points to the correct section. When linking the program with the linker flag '-gc-sections', lld can garbage- collect unused sections. In my case, the text section is correctly garbage- collected. However,  the linked debug section remains in...

>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make >sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by >default. I'll start investigating the

...ets of (<from input section>, >> <symbol>, <to input section>), which represents an edge, to reconstruct a >> graph. >> > > A couple of points: > > - Symbols are not the only kind of dependency edge from one section to > another -- there's also SHF_LINK_ORDER. Maybe we can just call the edge > "SHF_LINK_ORDER" in that case. > - Do we want to mark up the GC roots in some way? I imagine that we could > do that with a synthetic node that represents the GC root, and then have > all roots include edges from it. With my proposal for part...

Hi llvm-dev, I'm currently looking for alternatives to the synthetic references that XRay uses to keep some side-tables live, to avoid linker garbage collection from deleting those sections. Before going any further, let me give a backgrounder on what XRay does today. Background ========== XRay has two side tables we use at runtime to identify the location of the sleds for the functions

Hey, We would like to propose an idea that would help security harden applications that define custom sections. Motivation and Background In Chromium we have a garbage collector that implements some RTTI machinery in the form of a table. This table is used by the collector to trace and finalize garbage collected objects. We're thinking of using __attribute__((section(...))) so that the table

I performed tests basing on first diff of https://reviews.llvm.org/D40352. (Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of created .eh_frame section to point to corresponding .text.) With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when linking sample apps: ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o /usr/local/bin/ld: .eh_frame has both ordered [`.eh_frame'...

...lls between ARM and Thumb. - Thunk generation for B immediate. - Keeping track of which parts are ARM/Thumb. Support for TLS - Add relocation and relaxation support for standard and descriptor based models. Support for C++ exceptions: - Creation of a PT_ARM_EXIDX program header. - Support for the SHF_LINK_ORDER (used by .ARM.exidx). Support for range-extension - Thumb2 BL range is only 16 Mb, conditional branch range is only 1 Mb. Range extension thunks are likely to be needed for large programs. Support for big-endian ARM targets - ARMv6 and above has little-endian instructions and big-endian data. The...

Hi, I've heard people say that they want to analyze dependencies between object files at the linker level so that they can run a whole-program analysis which cannot be done at the compiler that works for one compilation unit at a time. I'd like to start a discussion as to what we can do with it and how to make it possible. I'm also sharing my idea about how to make it possible.

...al* > .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* > .gnu.linkonce.d.rel.ro.*) } > > This would have your table contiguous in the .data.rel.ro OutputSection > and can be found with the __RTTI_start and __RTTI_end symbols. It may not > work so well if you are using SHF_LINK_ORDER for the RTTI sections as some > linkers tend to handle these better when every InputSection in the > OutputSection has SHF_LINK_ORDER. > > Peter > > > ________________________________________ > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Anton >...

I encountered an issue when enabling code coverage for Android and would like to confirm my findings and ask for suggestions. Here is my finding: When -fprofile-instr-generate, an llvm_prf_data section gets created that has entries for each function in the TU. One of the entries is FunctionAddr which holds the address of the function. Underneath, it is a relocation so it gets patched with the

...n, // initialize type, entsize and flags from isec. hasInputSections = true; type = isec->type; entsize = isec->entsize; flags = isec->flags; } else { // Otherwise, check if new type or flags are compatible with existing ones. unsigned mask = SHF_TLS | SHF_LINK_ORDER; if ((flags & mask) != (isec->flags & mask)) error("incompatible section flags for " + name + "\n>>> " + toString(isec) + ": 0x" + utohexstr(isec->flags) + "\n>>> output section " + name +...

...creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers all function sections, which seems odd to me. On Thu, Oct 26, 2017 at 9:47 AM, Reid Kleckner <rnk at google.com> wrote: > Have you seen the discussion of SHF_LINK_ORDER on the generic-abi@ > mailing list? I think it implements exactly what you describe. My > understanding is that ARM EHABI leverages this for the same purpose. > > https://groups.google.com/forum/#!topic/generic-abi/_CbBM6T6WeM > > On Wed, Oct 25, 2017 at 6:42 PM, Rui Ueyama via ll...

...on the nature of the input package. On the other hand, depending on the nature of the input package, there can also be some big gains. 2) Devise a scheme that doesn't require any linker knowledge of DWARF. The current approach doesn't quite achieve this properly due to the slight misuse of SHF_LINK_ORDER, but I expect that a pivot to using non-COMDAT group sections should solve this problem. 3) Provide some kind of halfway house between simply writing tombstone values into dead DWARF and fully parsing the DWARF to reoptimise its/discard the dead bits. I'm hopeful that changes could be made to...

Hi, Many linkers including lld have a feature to eliminate unused sections from output to make output smaller (which is essentially a mark-sweep gc where sections are vertices and relocations are edges). lld and GNU gold have yet another feature, ICF, to merge functions by contents to save more space. When we remove or merge a function, we want to eliminate its exception handling information as

...y (-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 table. SHF_LINK_ORDER h...

...cede which section is lost, because the output order is written by the order of atoms that we processed. For example, if we have two object files 1.o and 2.o, each containing .text/.data sections in them and the .data section in the second file (2.o) specifies a particular link order by using (SHF_LINK_ORDER), the ordering from 2.o takes priority from the other ones and we seem to have lost that information when we read the Section right ? Also we may have differing alignment requirements for each section, but we have alignment information at the Atom level. > >> 2) We dont have a way to l...

...and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers all function sections, which seems odd to me. On Thu, Oct 26, 2017 at 9:47 AM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote: Have you seen the discussion of SHF_LINK_ORDER on the generic-abi@ mailing list? I think it implements exactly what you describe. My understanding is that ARM EHABI leverages this for the same purpose. https://groups.google.com/forum/#!topic/generic-abi/_CbBM6T6WeM On Wed, Oct 25, 2017 at 6:42 PM, Rui Ueyama via llvm-dev <llvm-dev at lists...

...gt; > >> > > > 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) > >> > > > > &...

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