similar to: Please dogfood LLD

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

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 Tue, Mar 14, 2017 at 12:07 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote: > > Date: Tue, 14 Mar 2017 11:39:22 -0700 > > From: Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > > > > 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

On Wed, Mar 15, 2017 at 2:55 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 14 Mar 2017, at 18:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > 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). > > We’re now using it with

I've dealt with similar issues on the LLDB side, I think I can help you with this. pl On 6 January 2017 at 09:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the info. I can reproduce the issue. But because of lack of cmake > knowledge, I don't know how to fix that now. If no one will take a look at > this, I'll investigate it. > > On

Michael Johnson <mpj at rowley.co.uk> writes: > Hi Rafael, >> Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >>> Hi Rui, >>> >>> Are there any plans to support the -defsym command line option? >> It doesn't look that hard, it was just never requested. What project is >> using it? > Not sure I understand

It builds fine but I cannot execute the resulting binary which aborts with the mentioned error.However I don't use LLVM_ENABLE_PROJECTS, I don't know if that changes the way libLLVM-4.0svn.so is linked... Cheers,Jonas Am Freitag, den 06.01.2017, 13:44 +0900 schrieb Rui Ueyama: > Hi Hahnfeld, > I just compiled with LLVM_LINK_LLVM_DYLIB enabled [1] and build lld with `ninja lld`. It

I'm compiling a release note for LLD, and I'd like to get you guy's input about the status of the following subsystems. - Current MIPS support - Current AArch64 support - LTO I think AArch64 and LTO are added after the last release, so everything we've made so far should be in the next release note. MIPS's situation is different though. Rui -------------- next part

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

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

>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 >gold+gdb_index for now (given the performance problems you mentioned, >sounds like I wasn't gaining much/anything in terms of link time by using >lld anyway). > >On Thu, Mar 16, 2017 at 11:17 AM Rui Ueyama

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

Hi, Now that 2016 is almost over, I wanted to look back and summarize the progress we've made to LLD this year, as I guess most people who are not looking closely at LLD don't know very well about the current status. I think I can say that this year was a fantastic year for LLD. Now I'm pretty sure that that is going to be a serious (and better, in my opinion) alternative to the

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 June 2016 at 18:47, Rui Ueyama <ruiu at google.com> wrote: > Renato, it is not appropriate to call it my and Rafael's pet project. Hi Rui, I apologise, that was wrong in all levels. I know how much other people have contributed, but these people are on the inside already, so their contributions are more easily accepted. We have been trying to contribute for more than a year

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

Hi all, I recently gave LLD a try and it definitely works fine. However one cannot build it together with LLVM_LINK_LLVM_DYLIB: ELF/Driver.cpp and ELF/DriverUtils.cpp pull in llvm/Support/CommandLine.h which defines the command line options so these global variables end up in libLLVM-4.0svn.so via liblldELF. If this shared library is then linked into bin/lld or bin/opt one gets errors because of

On 3 June 2016 at 17:10, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Do keep in mind you are comparing a 11 year old project and a 11 month > old one. There is a lot more churn on the 11 month old one. LLD is at least 5 years old. Every time you re-write it doesn't reset history. > Again, I am truly sorry we were unable to come up with a perfect > design the

On 28 October 2016 at 18:12, Ed Maste <emaste at freebsd.org> wrote: > It should be possible to search the path for ld.lld first, then ld, > but to me it seems like it will just be more confusing. Hum, for me it would be less confusing. :) GCC uses bfd by default, LLVM uses LLD. If you want to change, use -fuse-ld. What would be confusing in this scenario? > Clang's current

Hi, In the file lld/ELF/Driver.cpp in function getCompressDebugSections we can see that the current default for lld is no debug section compression. It looks like tools like gdb, valgrind, elfutils, gcc's backtrace lib currently support compressed symbols. Since perf can use libdw from elfutils, I guess it supports it too. Do you think it's time to enable compressed debug section by