similar to: [RFC] better link error messages

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

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

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

Hi all, I am experimenting with extending ELF. I want to add a custom ELF section, something similar to a 'SyntheticSection'. However, I'm not able to find documentation / doxygen for LLD code. Are there any existing examples of adding custom ELF sections at link time in LLVM framework? Is it possible? Any pointers? Thanks in advance!Cheers! -------------- next part -------------- An

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

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

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

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

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

E.g. Is it intended to be allowed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,

Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Mon, Nov 7, 2016 at 5:53 PM, Davide Italiano <davide at freebsd.org> wrote: > On Mon, Nov 7, 2016 at 4:43 PM, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The asan bootstrap bot is unhappy with lld. >> Rui, os someone, please take a look. >> >>

The asan bootstrap bot is unhappy with lld. Rui, os someone, please take a look. http://lab.llvm.org:8011/builders/sanitizer-x86_64- linux-bootstrap/builds/138/steps/check-lld%20asan/logs/stdio ==26011==ERROR: LeakSanitizer: detected memory leaks Direct leak of 184 byte(s) in 1 object(s) allocated from: #0 0x72fab0 in operator new(unsigned long)