similar to: llvm-dev Digest, Vol 153, Issue 85

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

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

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

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

Hi James, Thank you for the comments. >I think we're not terribly far from that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files

On 01.09.2020 20:07, David Blaikie wrote: > Fair enough - thanks for clarifying the differences! (I'd still lean a > bit towards this being dwz-esque, as you say "an extension of classic dwz" I doubt a little about "llvm-dwz" since it might confuse people who would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

Debuginfo folks, What is your opinion on this proposal? Do we need to work on better DWARFLinker library for now? or Can we start to integrate llvm-dwarfutil as a series of small patches? If it is OK to start integrating of llvm-dwarfutil, Is it OK to move llvm-objcopy implementation into separate library ObjCopy ? Thank you, Alexey. On 01.09.2020 20:18, James Y Knight wrote: > > >

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build

On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 June 2016 at 20:14, Sean Silva <chisophugis at gmail.com> wrote: > > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > > important special case we may be able to agree on. (and I say this as > > somebody that largely builds cross-compilers (targeting

David Blaikie <dblaikie at gmail.com> writes: >>> Selfhost clang. Whenever we get a warning from Clang we either fix >>> Clang or fix the build quite quickly. >> >> Not possible, > > Out of curiosity - why not? (sure, I realize everyone has internal > build systems, etc, that they're ultimately integrating LLVM into - > but that doesn't mean

On Thu, Jan 3, 2013 at 11:16 AM, <dag at cray.com> wrote: > David Blaikie <dblaikie at gmail.com> writes: > >> Selfhost clang. Whenever we get a warning from Clang we either fix >> Clang or fix the build quite quickly. > > Not possible, Out of curiosity - why not? (sure, I realize everyone has internal build systems, etc, that they're ultimately

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

On Wed, Jun 14, 2017 at 1:41 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, Jun 14, 2017 at 12:47 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Tue, Jun 13, 2017, 11:30 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 11:06 PM, David Blaikie <dblaikie at

Is the entry in your ODR table 64-bit? Sean mentioned that this is a birthday paradox situation, but I don't think we need that large hash values, as our aim is not to avoid any collisions. Small number of collisions is okay as it just slightly increases false negatives. I think it can even be 16-bit if space saving is important. If we choose 16-bit hash, the probability that an ODR violation

David Blaikie <dblaikie at gmail.com> writes: > Selfhost clang. Whenever we get a warning from Clang we either fix > Clang or fix the build quite quickly. Not possible, > If you want to fix the build such that LLVM can be built -Werror clean > with GCC the right solution is going to be to turn off -Wuninitialized > when the LLVM build system detects that it is using GCC

On Thu, Jun 15, 2017 at 1:14 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > I agree with Dave here. In the environment I work in, we regularly see > users ship objects and static archives to other users, and then never > update them, even though the linker moves on. If they did this with an > object file that had contents (such as the ODR information) that were