search for: symbolbodi

Hi all, This proposes a redesign of LLD’s symbol table in order to improve memory locality by minimizing indirection when resolving relocations. The key idea is that we perform symbol resolution by overwriting SymbolBodies, rather than by updating pointers. This is based on some ideas mentioned by Rafael on IRC. Conceptually, we split Symbol into a non-polymorphic part and a polymorphic part (a SymbolBody). The non-polymorphic part contains the flags that are currently stored in Symbol, while the polymorphic part...

tl;dr: it looks like we call SymbolBody::getVA about 5x more times than we need to Should we cache it or something? (careful with threads). Here is a link to a PDF of my Mathematica notebook which has all the details of my investigation: https://drive.google.com/open?id=0B8v10qJ6EXRxVDQ3YnZtUlFtZ1k There seem to be two main regimes that we redundantly call SymbolBody::getVA: 1. most

On Tue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: > I don't think getVA is particularly expensive, and if it is not expensive > I wouldn't cache its result. Did you experiment to cache getVA results? I > think you can do that fairly easily by adding a std::atomic_uint64_t to > SymbolBody and use it as a cache for getVA. > You're right,

On Tue, Feb 28, 2017 at 11:39 PM, Rui Ueyama <ruiu at google.com> wrote: > I also did a quick profiling a few months ago and noticed just like you > that scanRelocations consumes a fairly large percentage of overall > execution time. That caught my attention because at the time I was looking > for a place that I can parallelize. > > scanRelocations is not parallelizable

I'm copying some LLD code into my codebase like this: // workaround for LLD not exposing ability to convert .def to .lib #include <set> namespace lld { namespace coff { class SymbolBody; class StringChunk; struct Symbol; struct Export { StringRef Name; // N in /export:N or /export:E=N StringRef ExtName; // E in /export:E=N SymbolBody *Sym = nullptr; uint16_t Ordinal

On Wed, Jun 14, 2017 at 7:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Jun 14, 2017 at 4:24 PM, Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm copying some LLD code into my codebase like this: >> >> // workaround for LLD not exposing ability to convert .def to .lib >> >> #include <set> >>

Folks, I'd like propose a new error message format for LLD so that error message for undefined or duplicated symbols are more informative and easy to read. Below are examples of the current error messages (note that characters in red are actually red on terminal): *Undefined symbols* /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol

I saw this change come in yesterday: commit 572ad839e2f66eaa82ffc71b1061eb3d06a4d126 Author: Saleem Abdulrasool <compnerd at compnerd.org> Date: Thu Jun 15 20:39:58 2017 +0000 COFF: add support for lib mode usage When link is invoked with `/def:` and no input files, it behaves as if `lib.exe` was invoked. Emulate this behaviour, generating the import library from the

On Mar 24, 2017 5:22 PM, "Reid Kleckner" <rnk at google.com> wrote: I figured you might consider moving the basenames of the filename earlier in the diagnostic, something like: bin/ld.lld: *error:* duplicate symbol: lld::elf::MipsGotSection::addEntry(lld::elf::SymbolBody&, long, lld::elf::RelExpr) *>>> defined at* Writer.cpp:38 in

On Sat, Mar 25, 2017 at 6:56 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 03/24/2017 11:42 PM, Sean Silva via llvm-dev wrote: > > > > On Mar 24, 2017 5:22 PM, "Reid Kleckner" <rnk at google.com> wrote: > > I figured you might consider moving the basenames of the filename earlier > in the diagnostic, something like: >

On Fri, Mar 24, 2017 at 2:04 PM, Sean Silva <chisophugis at gmail.com> wrote: > I lile the idea of having it more structured and I think your suggested > format is the right direction. > > I think one principle should be that we assume that file names and symbol > names are "really long" (possibly wrapped by the terminal etc.). > Right. That's what we should

On 3/29/17 12:53 PM, Rui Ueyama via llvm-dev wrote: > Put it all together, the following error messages should work for > everybody. I'll create a patch to make this change and send it for > review. Thank you guys for the inputs! > > > Undefined symbol error: > > bin/ld.lld: error: undefined symbol: >

I am late on the thread, but I just want to say that the new format looks awesome! Thanks, Rafael On 29 March 2017 at 15:18, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > My bad. I intended this. > > Undefined symbol error: > > bin/ld.lld: error: undefined symbol: > lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, >

...here are a few things we can to do to fix the problem. 1. I'd like everybody to not add any more complexity to the relocation handler until we clean this up because as we add more code, it gets harder to refactor. Any patch to reduce complexity is welcome. 2. The fact that we don't create SymbolBodies for local symbols is one of the major factors to contribute that complexity. I experimented on creating them, and the performance penalty seemed to be within a few percent, so that's a good trade-off. I'll try that. We can offset that degradation with optimizations in other places. 3. We...

Hi, Rafael took some measurements to try to investigate the effect of the local symbols changes. I've been taking a look at the measurements he got and there were some interesting things we noticed. For starters, in the range of revisions tested (r263214 through r263471), we found that the commit for --build-id was the most noticeable, with slowdowns from 7% to 23% (note: these were

I've been working on supporting ARM/Thumb interworking thunks in LLD and have encountered a limitation that I think it is worth bringing up in a wider context. This is all LLD specific, apologies if I've abused llvm-dev here. TL;DR summary: - Thunks in lld may not work if they are added to InputSections that have already been scanned. - There is a short term fix, but in the longer term I

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back. Best regards, George.

Hi, I am working on support R_MIPS_HI16 / R_MIPS_LO16 in the new LLD and have a couple of questions. == Q1 In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses combined addend (AHI << 16) + (short)ALO where AHI is original R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 relocation [1]. There are two

On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007