similar to: [Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.

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

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

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 Mon, Jun 22, 2020 at 7:21 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. >> >> >> >> >I tend to agree - but I'm

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

>> >> >Alexey> Probably we could try to make DWARF easy to parsing, trimming, rewriting so that full DWARF >> >> >Alexey> parsing solution would not take too much time? >> >> >Alexey> >> >> >Alexey> f.e. -debug-types-section solution uses COMDAT sections to split and deduplicate types. >> >> >Alexey> That

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

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

Hi David, please find my comments inside: >>>Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? >>> - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. >>There are two general requirements: >> 1) Remove (or clean) invalid debug info. > >Perhaps a

>On 2020-06-22, Alexey Lapshin via llvm-dev wrote: >>>> >> >Alexey> Probably we could try to make DWARF easy to parsing, trimming, rewriting so that full DWARF >>>> >> >Alexey> parsing solution would not take too much time? >>>> >> >Alexey> >>>> >> >Alexey> f.e. -debug-types-section solution uses

It makes me sad that the linker (via a library or otherwise) has to be "DWARF-aware" to be able to effectively handle --gc-sections, COMDATs, --icf etc for debug info, without leaving large blocks of data kicking around. The patching to -1 (or equivalent) is probably a good lightweight solution (though I'd love it if it could be done based on section type in the future rather than

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

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

>On Fri, Jun 5, 2020 at 1:55 PM Alexey Lapshin <alapshin at accesssoftek.com> wrote: >> >> >> >> >> >DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, >> >> >certainly not when talking about function code. The overhead of a unit occurred only once per >> >> >translation unit, so that

FWIW, I think it's probably best to at least initially frame the discussion around non-configurable value for the sake of reducing the scope/possible surface area of the feature/users/etc. I'd probably only encourage adding the user-configurable flag if/when someone has a use case for it. On Thu, Jun 4, 2020 at 2:31 PM Fangrui Song <maskray at google.com> wrote: > > > On

>DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, >certainly not when talking about function code. The overhead of a unit occurred only once per >translation unit, so that expense was reasonably amortized. >Splitting functions into their own object-file sections and making them excludable is an evolution of >compiler/linker technology that

>> >> >DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, >> >certainly not when talking about function code. The overhead of a unit occurred only once per >> >translation unit, so that expense was reasonably amortized. >> > >> >Splitting functions into their own object-file sections and making them

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 Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own