similar to: Fragmented DWARF

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.

On Fri, Nov 6, 2020 at 2:32 AM James Henderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com> wrote: >> >> Hi James, >> >> On 05.11.2020 17:59, James Henderson wrote: >> >> (Resending with history trimmed to avoid it getting stuck in moderator

Hi James, On 05.11.2020 17:59, James Henderson wrote: > (Resending with history trimmed to avoid it getting stuck in moderator > queue). > > Hi Alexey, > > Just an update - I identified the cause of the "Generated debug info > is broken" error message when I tried to build things locally: the > `outStreamer` instance is initialised with the host Triple,

Debuginfo and linker folks, we (AccessSoftek) would like to suggest a proposal for removing obsolete debug info. If you find it useful we will be happy to work on improving it. Thank you for any opinions and suggestions. Alexey.     Currently when the linker does garbage collection a lot of abandoned debug info is left behind (see Appendix A for documentation). Besides inflated debug info size,

On 06.11.2020 13:32, James Henderson wrote: > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > Hi James, > > On 05.11.2020 17:59, James Henderson wrote: >> (Resending with history trimmed to avoid it getting stuck in >> moderator queue). >>

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 Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul

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

No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers

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

On Tue, Sep 24, 2019 at 11:22 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alexay, > > Thank you for the detailed explanation. The other question I have is, as > discussed above, about dsymutil. You said that dsymutil is not usable at > link-time. What does that mean? If we only have to emit an output file in > the usual way and then automatically

On Thu, Jun 4, 2020 at 8:27 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Wednesday, June 3, 2020 5:31 PM > > To: Robinson, Paul <paul.robinson at sony.com> > > Cc: jh7370.2008 at my.bristol.ac.uk; llvm-dev at lists.llvm.org > >

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

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

>> >> >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, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused

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

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

>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