similar to: LLD's default --build-id choice

On Wed, Jun 1, 2016 at 4:57 PM, Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Jun 01, 2016 at 03:21:08PM -0700, Rui Ueyama via llvm-dev wrote: > > In the first place, I believe it was not a good decision to make GCC (and > > therefore Clang) to pass --build-id option to the linker by default (it > was > > done in 2009

In r226336 I shove off 1.2 seconds out of 9.8 seconds for lld to link lld. That's done by parallelizing archive member parsing. But I realized that was not the slowest pass. The single slowest pass in LLD is LayoutPass. Only sort() at the last of Layoutpass::perform takes about 3 seconds (one third of total execution time). It is because the comparison function passed to sort, compareAtoms,

tl;dr: TLSDESC have solved most problems in formerly inefficient TLS access models, so I think we can drop TLS relaxation support from lld. lld's code to handle relocations is a mess; the code consists of a lot of cascading "if"s and needs a lot of prior knowledge to understand what it is doing. Honestly it is head-scratching and needs serious refactoring. I'm trying to simplify

On Mon, Jun 2, 2014 at 12:49 AM, Rui Ueyama <ruiu at google.com> wrote: > I agree to move these files to Core. Any objections? None here. - Michael Spencer > > On Mon, Jun 2, 2014 at 12:44 AM, Bas van den Berg > <b.van.den.berg.nl at gmail.com> wrote: >> >> The inverted dependency of Core to ReaderWriter via Simple.h was already >> present. >> My

The inverted dependency of Core to ReaderWriter via Simple.h was already present. My idea was to fix the problem before it gets bigger. My proposal would be to move Simple.h and Alias.h to Core. Similar to UndefinedAtom.h etc. It would be even nicer to make the naming consistent as well, since there already is UndefinedAtom.h SharedLibaryAtom.h etc Maybe: SimpleAtom.h AliasAtom.h Moving the file

But I can't think of a reason that valgrind needs executable data segment. It is likely that valgrind assumes some specific segment layout that the GNU linker creates and can't handle other layout even if it is valid. On Thu, Apr 5, 2018 at 3:21 PM Rui Ueyama <ruiu at google.com> wrote: > --rosegment puts read-only data and executable text in a single segment > and make it

--rosegment puts read-only data and executable text in a single segment and make it executable, so your read-only code becomes executable. I think that shouldn't be a default behavior. If valgrind needs that, we can't fix it by changing the default. On Thu, Apr 5, 2018 at 2:50 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Confirmed that -no-rosegment

Hi, I've been following the changes in LLD's software architecture. Recently a new file was added: Alias.h In this file, the curret Atom set is extended with an AliasAtom. While the change seems innocent enough, it has some nasty potential. Simple.h and Alias.h are placed in the ReaderWriter component. This is the 2nd component in the layering: Driver ReaderWriter Passes Core The problem

What program did you use to test the feature, and what was missing information? I'd like to file that as a bug so that we can fix this later. On Thu, Mar 16, 2017 at 2:34 PM, David Blaikie <dblaikie at gmail.com> wrote: > FWIW - selfhosting I did find that GDB wasn't able to find the source code > for some functions when using LLD's gdb_index, so I've switched back to

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that.

I personally haven't tried gdb_index, and I don't know the quality of the produced index. Most of the code was written by George. One thing I noticed about the feature (and filed as http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index feature is much slower than the gold. Apparently there's room for improvement. On Thu, Mar 16, 2017 at 8:35 AM, David Blaikie <dblaikie

On Mon, Oct 23, 2017 at 6:40 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: > > > On Mon, Oct 23, 2017 at 9:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> On Mon, Oct 23, 2017 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com> >> wrote: >> >>> For Zig we use LLD as a library. So for us it would be better to avoid >>>

I fixed the immediate problem - please let me know when you are going to break my build so I can switch to maintaining it locally. thanks Iain ] On 13 Mar 2015, at 17:04, Rui Ueyama wrote: > Looks like most developers prefer Makefile removal, and there's no push-back. Let's go ahead and remove them. I'll send a patch. > > On Wed, Mar 11, 2015 at 3:33 PM, Iain Sandoe <iain

It is unfortunate that we are using a different coding scheme for LLD than LLVM, but I'm leaning toward the view that switching to LLVM style will cost too much if it means we are going to lose virtually all commit history. A patch to switch to LLVM style would rename all local and member variables, so it would touch all the lines. Diff is not powerful enough to trace the history beyond

The direct cause of this issue is that, previously lld converted common symbols to defined symbols before passing input files to LTO, and after r360841 they are passed as common symbols to LTO. Making lld to work as before is easy, as we can convert common symbols to defined symbols as before. Here is a patch to do that, and I confirmed that that restores the original behavior for the reported

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 think having diagnostics interface similar to Clang's would be good. I think the total number of defined warnings would be much smaller than Clang. On Mon, Oct 7, 2013 at 3:19 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Ping ? > > > On 10/4/2013 10:41 PM, Shankar Easwaran wrote: > >> Hi, >> >> lld doesnot have a Diagnostics interface, It

On Mon, Oct 23, 2017 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: > For Zig we use LLD as a library. So for us it would be better to avoid > global state such as SIGBUS (or any other signal handlers), instead > returning an error from the link function when linking fails. If lld can > encapsulate this signal handling and prevent the application using lld from >

Hi all, LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS). I believe you've heard a few good news about the linker -- it just works <http://lld.llvm.org/#features> and is very fast <http://lld.llvm.org/#performance>, clean, compact and supported by the active community. I don't think I need to

I guess I'm talking about atoms. Do we have notion of section in LLD? On Wed, Mar 25, 2015 at 8:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/24/2015 7:51 PM, Rui Ueyama wrote: > >> On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com>