search for: sh_link

On Tue, May 22, 2018 at 6:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only to sections which can be safely merged according to the guarantees > provided by the language. It works using a set of heuristics (symbol name > matching and relocation scanning).

...rbage collection and eliminates the need to parse .eh_frame contents. It also makes it very easy to compare .eh_frame sections for function merging. 2. Make each .eh_frame section have a link to its .text section. We could set a section index of a .text section to its corresponding .eh_frame's sh_link field. This would make gc much easier. (If text section A is pointed by an .eh_frame section B via sh_link, that A is alive means B is alive. It is still reverse, but this is much more manageable.) I think doing the above things doesn't break the compatibility with existing linkers, and new li...

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan

...parse .eh_frame contents. It also makes it very easy >> to compare .eh_frame sections for function merging. >> >> 2. Make each .eh_frame section have a link to its .text section. We could >> set a section index of a .text section to its corresponding .eh_frame's >> sh_link field. This would make gc much easier. (If text section A is >> pointed by an .eh_frame section B via sh_link, that A is alive means B is >> alive. It is still reverse, but this is much more manageable.) >> >> I think doing the above things doesn't break the compatibilit...

>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

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' in /tmp/tes...

...rbage collection and eliminates the need to parse .eh_frame contents. It also makes it very easy to compare .eh_frame sections for function merging. 2. Make each .eh_frame section have a link to its .text section. We could set a section index of a .text section to its corresponding .eh_frame's sh_link field. This would make gc much easier. (If text section A is pointed by an .eh_frame section B via sh_link, that A is alive means B is alive. It is still reverse, but this is much more manageable.) I think doing the above things doesn't break the compatibility with existing linkers, and new li...

...symbol table"); + ret = read(elf_fd, syms, sec[i].sh_size); + if (ret != sec[i].sh_size) + err(1, "Reading symbol table"); + nsyms = sec[i].sh_size / sizeof(Elf64_Sym); + + + /* symtab links to strtab. We use it to find symbol + * names */ + strtab = malloc(sec[sec[i].sh_link].sh_size); + if (!strtab) + err(1,"Not enough memory for string table"); + ret = lseek(elf_fd, sec[sec[i].sh_link].sh_offset , SEEK_SET); + if (ret < 0) + err(1, "Seeking to string table"); + ret = read(elf_fd, strtab, sec[sec[i].sh_link].sh_size); + if (ret !...

...symbol table"); + ret = read(elf_fd, syms, sec[i].sh_size); + if (ret != sec[i].sh_size) + err(1, "Reading symbol table"); + nsyms = sec[i].sh_size / sizeof(Elf64_Sym); + + + /* symtab links to strtab. We use it to find symbol + * names */ + strtab = malloc(sec[sec[i].sh_link].sh_size); + if (!strtab) + err(1,"Not enough memory for string table"); + ret = lseek(elf_fd, sec[sec[i].sh_link].sh_offset , SEEK_SET); + if (ret < 0) + err(1, "Seeking to string table"); + ret = read(elf_fd, strtab, sec[sec[i].sh_link].sh_size); + if (ret !...

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> 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

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

This adds [f]getc() and fgets() for parsing config files. Probably hard to avoid. Still trying to decide if I actually want to add system() or not. -hpa

Hi! If there is a string table for section headers, it also gets loaded. Therefore take it into account in size calculation for kernel symtab. Also there is no need to call elf_set_verbose() a second time after elf_init() (First call happens within elf_init()). Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> Keir: Can you also apply changeset 15672 and this patch to Xen

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 the program and re...

Hello, all experts. When I use pid provider, my Dscript with -F option output the codepath with flowindent as you know, e.g. -> main -> f1 -> f2 however I realized that the exec file I used at that time was stripped. Does anyone know the reason why I could see the function names? Thanks in advance. -- This message posted from opensolaris.org

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

...sing SHT_NULL, global and local symbols out of order, etc.) 4. Sticking close to the spec -- Sean Silva > > One thing this doesn't cover is dynamic symbol table vs the normal > symbol table, as both can be referenced by relocations in the same > ELF. This is modeled in ELF by the sh_link field. Not sure how we > should do it here (do we even support dynamic symbol tables yet?). > > - Michael Spencer > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140407/9f0fa710/attachment.html&...

...ing that "LLVM is experimenting with placing .eh_frame sections in the COMDAT group", that is true for original experiment which faced this gold issue (https://marc.info/?l=llvm-commits&m=144683596826489), current approach I am experimented with (https://reviews.llvm.org/D40352) sets sh_link of .eh_frame to corresponding .text section instead. Though anyways issue looks to be that gold did not like to have multiple .eh_frame sections and that is what both approaches faced with and your patch seeems fixes that. George.

Hi Peter, This is a great proposal, thanks!. If you were worried about making the abi change have you thought about just going for an array of symbol names or hashes of symbol names where any matching symbol is considered address significant? This would sidestep the problem of keeping the symbol table indices in sync. It would be pessimistic for local symbols if the input SHT_ADDRSIG sections

>Keeping .eh_frame separated should still simplifies the linker because >until the last step of building .eh_frame and .eh_frame_hdr, we don't >really need to parse .eh_frame sections. So, if we have separate .eh_frame >sections on -ffunction-sections, all we have to do is (1) garbage-collect >sections and (2) construct .eh_frame and .eh_frame_hdr sections from live