On Thu, Apr 15, 2021 at 2:43 PM pawel k. via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hiya, > > Enormous thanks for all suggests and extensive too. Testing splitdwarf asap. > > Makes me think what i thought previously. We need dwarf go pdbish way.Split DWARF provides something like this, though with some different tradeoffs - for instance Split DWARF is easier to use in a distributed build (since the compiler doesn't have to communicate with a separate server while it's compiling).> Separate dblike possibly adressable by url.Symbol servers are another problem - even using classic DWARF you can then strip the main binary, keep the unstripped binary and put that unstripped binary on some kind of symbol server system (I'm not sure if gdb supports something like that natively, but could be done without DWARF changes).> I was hacking pdb techno before it got sexy. I know a bit how it is organized and could try to help with architecting or designing such solution. Loved dbinfo on vstudio. Gdbish not so much.What sort of problems have you had with gdb or the DWARF debugging workflow more generally?> And i was slaving on my corpo cotton plantation passively using gdb for about a decade.(analogies to slavery aren't suitable for this community) - Dave> > If catches anyones focus, lets discuss the solution. > > Best regards, > Pawel Kunio > > czw., 15.04.2021, 23:37 użytkownik Min-Yih Hsu <minyihh at uci.edu> napisał: >> >> You can use `LLVM_USE_LINKER=lld` CMake variable to adopt LLD (to build LLVM). And yes, LLD takes less memory and runs faster. Here are some other tips to save memory: >> 1. You can use `LLVM_PARALLEL_LINK_JOBS=N` (also a cmake variable) to limit the amount of parallel linker jobs to save some memory. >> >> 2. Build libraries as shared library via `BUILD_SHARED_LIBS=ON` CMake variable can dramatically speed up the linking time and save you some memory. >> >> 3. Since you’re building a Debug build (and you’re building on Linux), `LLVM_USE_SPLIT_DWARF` can dramatically reduce the size of debug info, which, to some extend, also save you some memory during link time. >> >> Best, >> -Min >> > On Apr 15, 2021, at 1:05 PM, pawel k. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> > >> > Hello, >> > Im trying to build trunk clang in debug version on oldish ubuntu with low mem. Linking lli takes ages and fails on low mem. Is there a chance building would succeed if i used lld instead of ld? If so is there an option either to force lld or whole clang toolchain use in cmake instead of default gcc (both gcc and clang are avail on system)? Otherwise I think ill stick with release. >> > >> > Best regards, >> > Pawel Kunio >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
As on company remark sorry. Wasnt aware of netiquette. Please rm this msg if need be. Ok for gdb, load time was major pain. Type casting was patchy some types missing etc, some var tracking especially under optimizations was tricky for example having to cast registers because info this var is stored in this register was missing hmm also one mire thing that could minimize debug info size could be shared types section with removing local copies per compilation unit. Also global vars etc could be stored in shared segment. Also we could think of somehow indexing the db. My other idea is indeed distributing stripped binaries and devels keeping debug info dbs snapshots locally or via debug servers. If we dont wanna debug servers, stack traces etc should contain stack dumps maybe or some in the middle solution with lineinfo only possibly hashed etc. Best regards, Pawel Kunio pt., 16.04.2021, 01:06 użytkownik David Blaikie <dblaikie at gmail.com> napisał:> On Thu, Apr 15, 2021 at 2:43 PM pawel k. via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hiya, > > > > Enormous thanks for all suggests and extensive too. Testing splitdwarf > asap. > > > > Makes me think what i thought previously. We need dwarf go pdbish way. > > Split DWARF provides something like this, though with some different > tradeoffs - for instance Split DWARF is easier to use in a distributed > build (since the compiler doesn't have to communicate with a separate > server while it's compiling). > > > Separate dblike possibly adressable by url. > > Symbol servers are another problem - even using classic DWARF you can > then strip the main binary, keep the unstripped binary and put that > unstripped binary on some kind of symbol server system (I'm not sure > if gdb supports something like that natively, but could be done > without DWARF changes). > > > I was hacking pdb techno before it got sexy. I know a bit how it is > organized and could try to help with architecting or designing such > solution. Loved dbinfo on vstudio. Gdbish not so much. > > What sort of problems have you had with gdb or the DWARF debugging > workflow more generally? > > > And i was slaving on my corpo cotton plantation passively using gdb for > about a decade. > > (analogies to slavery aren't suitable for this community) > > - Dave > > > > > If catches anyones focus, lets discuss the solution. > > > > Best regards, > > Pawel Kunio > > > > czw., 15.04.2021, 23:37 użytkownik Min-Yih Hsu <minyihh at uci.edu> > napisał: > >> > >> You can use `LLVM_USE_LINKER=lld` CMake variable to adopt LLD (to build > LLVM). And yes, LLD takes less memory and runs faster. Here are some other > tips to save memory: > >> 1. You can use `LLVM_PARALLEL_LINK_JOBS=N` (also a cmake variable) to > limit the amount of parallel linker jobs to save some memory. > >> > >> 2. Build libraries as shared library via `BUILD_SHARED_LIBS=ON` CMake > variable can dramatically speed up the linking time and save you some > memory. > >> > >> 3. Since you’re building a Debug build (and you’re building on Linux), > `LLVM_USE_SPLIT_DWARF` can dramatically reduce the size of debug info, > which, to some extend, also save you some memory during link time. > >> > >> Best, > >> -Min > >> > On Apr 15, 2021, at 1:05 PM, pawel k. via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > > >> > Hello, > >> > Im trying to build trunk clang in debug version on oldish ubuntu with > low mem. Linking lli takes ages and fails on low mem. Is there a chance > building would succeed if i used lld instead of ld? If so is there an > option either to force lld or whole clang toolchain use in cmake instead of > default gcc (both gcc and clang are avail on system)? Otherwise I think ill > stick with release. > >> > > >> > Best regards, > >> > Pawel Kunio > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > llvm-dev at lists.llvm.org > >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://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/20210416/817d7b37/attachment-0001.html>
Hi, Also if that matters on winxp mingw x8632 arch debug command responsiveness was measured in tens/hundreds of milis while same in vc it was in few nanos approximately and it was common for most archs. Seemed like gdb antifeature more than trap exception handling kind of problem but speculating here. Best regards, Pawel Kunio pt., 16.04.2021, 01:06 użytkownik David Blaikie <dblaikie at gmail.com> napisał:> On Thu, Apr 15, 2021 at 2:43 PM pawel k. via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hiya, > > > > Enormous thanks for all suggests and extensive too. Testing splitdwarf > asap. > > > > Makes me think what i thought previously. We need dwarf go pdbish way. > > Split DWARF provides something like this, though with some different > tradeoffs - for instance Split DWARF is easier to use in a distributed > build (since the compiler doesn't have to communicate with a separate > server while it's compiling). > > > Separate dblike possibly adressable by url. > > Symbol servers are another problem - even using classic DWARF you can > then strip the main binary, keep the unstripped binary and put that > unstripped binary on some kind of symbol server system (I'm not sure > if gdb supports something like that natively, but could be done > without DWARF changes). > > > I was hacking pdb techno before it got sexy. I know a bit how it is > organized and could try to help with architecting or designing such > solution. Loved dbinfo on vstudio. Gdbish not so much. > > What sort of problems have you had with gdb or the DWARF debugging > workflow more generally? > > > And i was slaving on my corpo cotton plantation passively using gdb for > about a decade. > > (analogies to slavery aren't suitable for this community) > > - Dave > > > > > If catches anyones focus, lets discuss the solution. > > > > Best regards, > > Pawel Kunio > > > > czw., 15.04.2021, 23:37 użytkownik Min-Yih Hsu <minyihh at uci.edu> > napisał: > >> > >> You can use `LLVM_USE_LINKER=lld` CMake variable to adopt LLD (to build > LLVM). And yes, LLD takes less memory and runs faster. Here are some other > tips to save memory: > >> 1. You can use `LLVM_PARALLEL_LINK_JOBS=N` (also a cmake variable) to > limit the amount of parallel linker jobs to save some memory. > >> > >> 2. Build libraries as shared library via `BUILD_SHARED_LIBS=ON` CMake > variable can dramatically speed up the linking time and save you some > memory. > >> > >> 3. Since you’re building a Debug build (and you’re building on Linux), > `LLVM_USE_SPLIT_DWARF` can dramatically reduce the size of debug info, > which, to some extend, also save you some memory during link time. > >> > >> Best, > >> -Min > >> > On Apr 15, 2021, at 1:05 PM, pawel k. via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > > >> > Hello, > >> > Im trying to build trunk clang in debug version on oldish ubuntu with > low mem. Linking lli takes ages and fails on low mem. Is there a chance > building would succeed if i used lld instead of ld? If so is there an > option either to force lld or whole clang toolchain use in cmake instead of > default gcc (both gcc and clang are avail on system)? Otherwise I think ill > stick with release. > >> > > >> > Best regards, > >> > Pawel Kunio > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > llvm-dev at lists.llvm.org > >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://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/20210416/e5e6f3f0/attachment.html>