similar to: [Proposal][Debuginfo] dsymutil-like tool for ELF.

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)

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

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

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

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

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

Hi Alexey, I should've looked at this earlier. I went through the thread again and I've made some comments, mostly from the dsymutil point of view. > Current DWARFEmitter/DWARFStreamer has an implementation for DWARF > generation, which does not support DWARF5(only debug_names table). At the > same time, there already exists code in CodeGen/AsmPrinter/DwarfDebug.h, > which

Hi Eric, please On 31.07.2020 22:02, Eric Christopher wrote: > Hi Alexey, > > On Fri, Jul 31, 2020 at 4:02 AM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 28.07.2020 19:28, David Blaikie wrote: > > On Tue, Jul 28, 2020 at 8:55 AM Alexey Lapshin > <avl.lapshin at gmail.com

On 28.07.2020 19:28, David Blaikie wrote: > On Tue, Jul 28, 2020 at 8:55 AM Alexey Lapshin <avl.lapshin at gmail.com> wrote: >> >> On 28.07.2020 10:29, David Blaikie via llvm-dev wrote: >>> On Fri, Jun 26, 2020 at 9:28 AM Alexey Lapshin >>> <alapshin at accesssoftek.com> wrote: >>>>>>>>>>>> This idea goes in another

I'm seeing a bunch of failures on AArch64 after updating this morning. These are NOT failing on x86-64. These all seem to be caused by segfaults (example backtrace below). Is anyone else seeing this? -David LLVM :: DebugInfo/symbolize-no-debug-str.test LLVM :: tools/gold/X86/comdat.ll LLVM :: tools/gold/X86/visibility.ll LLVM ::

> On Feb 28, 2020, at 11:25 PM, Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 2020-02-28, Greg Clayton via llvm-dev wrote: >> I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as

I'd like it... Adrian? Fred? -eric On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <clayborg at gmail.com> wrote: > Yes. I am fine with adding ELF support to llvm-dsymutil if that is the way > people think we should go? > > On Mar 2, 2020, at 3:33 PM, Eric Christopher <echristo at gmail.com> wrote: > > Which seems like what we'd want dsymutil to do anyhow? >

Which seems like what we'd want dsymutil to do anyhow? -eric On Mon, Mar 2, 2020 at 3:21 PM Greg Clayton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On other options would be to make a new "llvm-dwarfld" tool, where most of > the functionality would exist llvm/lib/DwarfLinker and other locations. The > idea would be to do any post processing to DWARF using

Is there/could you further explain the use-case for adding an index to an existing binary? Certainly not the worst idea/could come in handy sometimes, but you mention benchmarking - is the benefit of not recompiling/relinking that significant to such experiments? If it's not for use in a common workflow, but only in a compiler/debugger development workflow, it doesn't seem so important to

On 28.07.2020 10:29, David Blaikie via llvm-dev wrote: > On Fri, Jun 26, 2020 at 9:28 AM Alexey Lapshin > <alapshin at accesssoftek.com> wrote: >> >>>>>>>>>> This idea goes in another direction than fragmenting dwarf >>>>>>>>>> using elf sections&tricks. It seems to me that the cost of fragmenting is too high.

>> >> >> >> This idea goes in another direction than fragmenting dwarf >> >> >> >> using elf sections&tricks. It seems to me that the cost of fragmenting is too high. >> >> >> >> >> >> >I tend to agree - but I'm sort of leaning towards trying to use object >> >> >> >features as much

On Mon, Aug 10, 2020 at 5:15 AM Alexey Lapshin <avl.lapshin at gmail.com> wrote: > > Hi Jonas, > > Thank you for the comments, please find my answers below... > > On 06.08.2020 20:39, Jonas Devlieghere wrote: > > Hi Alexey, > > I should've looked at this earlier. I went through the thread again and I've > made some comments, mostly from the dsymutil

Thanks for copying me in Paul! Sorry, for the late reply. I have had a personal interest in this subject for a long time and I have had discussions on linking DWARF with many of you in person at LLVM events. I don't have much to add to what's upthread and James Henderson has already answered the questions I was copied in for. However, I did want to make a general point about ELF that I

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage