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 > 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/543928ac/attachment.html>
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/e4abc60a/attachment.html>
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/bf64e74a/attachment-0001.html>