similar to: DebugInfo proposal: Emit an explicit empty address range on CUs with no code addresses

On Wed, Nov 28, 2018 at 9:47 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 28, 2018, at 9:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > So I've been looking at a particular performance problem with LLVM's > symbolizer due to the use of ThinLTO, split DWARF, and split DWARF inlining > info. > > > > This

On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com> wrote: > > > On May 3, 2017, at 2:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > So Dehao and I have been dealing with some of the nitty gritty details > of debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as well, so I

> On May 3, 2017, at 7:43 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 3, 2017, at 2:59 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:

Sorry, trying to catch up a bit late… It sounds like having more than one CU per .dwo is outside of the intention of the DWARF specification (though not explicitly forbidden), since there is an implied 1-1 relationship between skeleton CU and .dwo. There is an explicit 1-1 relationship between skeleton CU and split-full CU (not .dwo). This suggests to me that if you want a .dwo to have multiple

So Dehao and I have been dealing with some of the nitty gritty details of debug info with ThinLTO, specifically with Fission(Split DWARF). This applies to LTO as well, so I won't single out ThinLTO here. 1) Multiple CUs in a .dwo file Clang/LLVM produces a CU for each original source file - these CUs are kept through IR linking (thin or full) and produced as distinct CUs in the resulting

Yeah, fair - I'll give it a week or something, see if Paul or anyone else has ideas about why the existing behavior might be useful before I remove it. On Wed, Nov 28, 2018 at 10:27 AM Adrian Prantl <aprantl at apple.com> wrote: > > On Nov 28, 2018, at 9:50 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > a) decide that a unit without ranges covers no

Much like the recent efforts to provide a port of dsymutil in the LLVM project, I'm looking at providing an implementation of the Fission/Split DWARF DWP tool ( https://gcc.gnu.org/wiki/DebugFissionDWP ) in LLVM. While there's potentially some overlap between the two tools, I'm thinking of keeping them separate at least initially since much of the debug info doesn't need to be

On Tue, Nov 3, 2015 at 5:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > SGTM. This will bring us closer to the point when we can write tests, > where we strip out the .dwo files from executables, package them together > with llvm-dwp, and then verify that we still get all we need from > llvm-symbolizer. > Not quite following here - dwo sections are already stripped

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

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

>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

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

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

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

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 May 4, 2017, at 4:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Alrighty, a little fuzzy on how best to implement this - Adrian, you've probably got the most context here as to how to wrangle this. > > My first attempt was in IRMover.cpp, IRLinker::linkFunctionBody - after metadata is copied over, create a new subprogram derived from Dst.getSubprogram,

>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

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