[llvm-dev] Please dogfood LLD

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 14:46:03 PDT 2017


Thanks. Filed as http://bugs.llvm.org/show_bug.cgi?id=32319.

On Thu, Mar 16, 2017 at 2:41 PM, David Blaikie <dblaikie at gmail.com> wrote:

> To be specific - you can see a few of the later frames (endFunction,
> runOnMachineFunction, runOnFunction) doesn't have source information.
>
> On Thu, Mar 16, 2017 at 2:40 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Thu, Mar 16, 2017 at 2:36 PM Rui Ueyama <ruiu at google.com> wrote:
>>
>> 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.
>>
>>
>> I was using GDB 7.9 (a google internal build, not sure how much that
>> matters - there might be some things that didn't make it upstream) to debug
>> LLVM's 'llc' binary on an assert-failure.
>>
>> The backtrace was missing source information from some frames:
>>
>> Not the best representation of it, but here's a chunk of my debugging
>> session:
>>
>> #9  0x00000000037d9278 in llvm::DwarfCompileUnit::constructVariableDIEImpl
>> (this=0x540a390, DV=..., Abstract=false) at /usr/local/google/hom
>> e/blaikie/dev/llvm/src/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:543
>> (gdb)
>> #10 0x00000000037d8c6c in llvm::DwarfCompileUnit::constructVariableDIE
>> (this=0x540a390, DV=..., Abstract=false) at /usr/local/google/home/bl
>> aikie/dev/llvm/src/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:479
>> (gdb)
>> #11 0x00000000037d97b6 in llvm::DwarfCompileUnit::constructVariableDIE
>> (this=0x540a390, DV=..., Scope=..., ObjectPointer=@0x7fffffffb488: 0x
>> 0) at /usr/local/google/home/blaikie/dev/llvm/src/lib/CodeGen/AsmPrinter/
>> DwarfCompileUnit.cpp:560
>> (gdb)
>> #12 0x00000000037d8231 in llvm::DwarfCompileUnit::createScopeChildrenDIE
>> (this=0x540a390, Scope=0x5482df0, Children=llvm::SmallVector of len
>> gth 0, capacity 8, ChildScopeCount=0x0) at /usr/local/google/home/
>> blaikie/dev/llvm/src/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:572
>> (gdb)
>> #13 0x00000000037d99b7 in llvm::DwarfCompileUnit::createAndAddScopeChildren
>> (this=0x540a390, Scope=0x5482df0, ScopeDIE=...) at /usr/local/go
>> ogle/home/blaikie/dev/llvm/src/lib/CodeGen/AsmPrinter/
>> DwarfCompileUnit.cpp:614
>> (gdb)
>> #14 0x00000000037d98a4 in llvm::DwarfCompileUnit::constructSubprogramScopeDIE
>> (this=0x540a390, Sub=0x53cd568, Scope=0x5482df0) at /usr/local
>> /google/home/blaikie/dev/llvm/src/lib/CodeGen/AsmPrinter/
>> DwarfCompileUnit.cpp:594
>> (gdb)
>> #15 0x000000000376a087 in llvm::DwarfDebug::endFunctionImpl
>> (this=0x54082c0, MF=0x5439b60) at /usr/local/google/home/
>> blaikie/dev/llvm/src/li
>> b/CodeGen/AsmPrinter/DwarfDebug.cpp:1240
>> (gdb)
>> #16 0x00000000037c93c9 in llvm::DebugHandlerBase::endFunction(llvm::MachineFunction
>> const*) ()
>> (gdb)
>> #17 0x0000000003733d6a in llvm::AsmPrinter::EmitFunctionBody
>> (this=0x53fa9a0) at /usr/local/google/home/blaikie/dev/llvm/src/lib/
>> CodeGen/Asm
>> Printer/AsmPrinter.cpp:1083
>> (gdb)
>> #18 0x0000000003107e61 in llvm::X86AsmPrinter::
>> runOnMachineFunction(llvm::MachineFunction&) ()
>> (gdb)
>> #19 0x0000000003a263b1 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
>> ()
>>
>>
>>
>> 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 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 <ruiu at google.com> wrote:
>>
>> 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 at gmail.com>
>> wrote:
>>
>> Any idea of the quality/completeness of the gdb_index support? I've
>> started using gdb_index recently (reduces GDB startup time for Clang from
>> 50 seconds to 3 seconds - though I haven't measure how much it increases
>> link time*) & it's really handy. Would love to have some assurance it's
>> expected to work for LLD.
>>
>> Simple experiments seem to indicate that it's OK/good. Though a quick
>> llvm-dwarfdump of gdb_index between the two linkers shows about a 10%
>> disparity in size (LLD's is smaller) given the same inputs. (219MB v 196MB
>> of text dumped - I didn't compare the actual section sizes)
>>
>> *though honestly I'd be willing to trade startup time for link time 1:1
>> even, because builds/links are already long enough that I go off and do
>> something else - whereas getting GDB start down to 3 seconds, I can start
>> writing my breakpoint command, etc, in those 3 seconds and be all but
>> unaffected by it - at 50 seconds I basically have to go off and do
>> something else/context switch/etc.
>>
>> On Tue, Mar 14, 2017 at 11:40 AM Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> 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 reiterate why having a good
>> linker is important for us as the LLVM community.
>>
>> There's one thing you can help us without writing even a line of code.
>> Please use it!
>>
>> Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD
>> repository just like you probably already did for clang, build it, and then
>> install it. LLD will be installed as ld.lld (and it won't be used by
>> default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with
>> your usual options so that LLD will be used to build LLVM.
>>
>> For the details of the build process, please see
>> http://lld.llvm.org/#build.
>>
>> Thanks,
>> Rui
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/1d355ca6/attachment.html>


More information about the llvm-dev mailing list