search for: dwos

There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations). In

...dr section in the main .o file, which allows the DWO to >> contain DIEs/attributes that should have address values, because the actual >> address values are still in the .o file; but before that anything that's an >> address really can't go into the DWO. >> > > DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as > they did exist (in a non-standard form) they have always supported > FORM_addr_index to reference addresses in .debug_addr in the main .o. > > But the low_pc/high_pc/ranges attributes would appear in the .dwo, usi...

...lows the DWO to > >> contain DIEs/attributes that should have address values, because the > actual > >> address values are still in the .o file; but before that anything > that's an > >> address really can't go into the DWO. > >> > > > > DWOs didn't exist (in a standard form) before DWARF 5, right? Insofar as > > they did exist (in a non-standard form) they have always supported > > FORM_addr_index to reference addresses in .debug_addr in the main .o. > > > > But the low_pc/high_pc/ranges attributes would app...

...ches to handle (1)+Fission, it's still not enough - needs > more work) > > Binutils DWP and the DWP format in general... maybe can't cope with this. > > > > Talking about (2)+DWP: > > You mean (2)+DWO+DWP? > DWP is a package containing the contents of multiple DWOs - so, yes and no? Not sure how to answer. (2)+DWO could be made to work without changing much in the contents/format/etc, I think - consumers could be made to understand the 'obvious' form (no change to producers I think would be needed). But once you go to a DWP file, then there are repr...

...t's still not enough - needs more work) >> > Binutils DWP and the DWP format in general... maybe can't cope with this. >> > >> > Talking about (2)+DWP: >> >> You mean (2)+DWO+DWP? >> >> DWP is a package containing the contents of multiple DWOs - so, yes and no? Not sure how to answer. >> >> (2)+DWO could be made to work without changing much in the contents/format/etc, I think - consumers could be made to understand the 'obvious' form (no change to producers I think would be needed). >> >> But once you g...

...t get this far - but even with patches to handle (1)+Fission, it's still not enough - needs more work) > Binutils DWP and the DWP format in general... maybe can't cope with this. > > Talking about (2)+DWP: You mean (2)+DWO+DWP? DWP is a package containing the contents of multiple DWOs - so, yes and no? Not sure how to answer. (2)+DWO could be made to work without changing much in the contents/format/etc, I think - consumers could be made to understand the 'obvious' form (no change to producers I think would be needed). But once you go to a DWP file, then there are repr...

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

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

...disk space required to keep >> all of these builds. >Ah, OK - for archival purposes. So the interactive developers wouldn't >necessarily be using this feature. Makes sense - similar to dsymutil >and dwp, mostly used for archival purposes & you can debug straight >from .o/.dwos for interactive/iterative development. >In that case, it seems more likely that a separate tool might suffice. agreed: if to continue the work on this then it makes sense to do it as separate tool. Make it fast enough. And if there would be interest in it - then it would probably be possible...

...; all of these builds. >>> Ah, OK - for archival purposes. So the interactive developers wouldn't >>> necessarily be using this feature. Makes sense - similar to dsymutil >>> and dwp, mostly used for archival purposes & you can debug straight >> >from .o/.dwos for interactive/iterative development. >> >>> In that case, it seems more likely that a separate tool might suffice. >> agreed: if to continue the work on this then it makes sense to >> do it as separate tool. Make it fast enough. And if there would be interest >> i...

...gt;>> Ah, OK - for archival purposes. So the interactive developers wouldn't >>>>> necessarily be using this feature. Makes sense - similar to dsymutil >>>>> and dwp, mostly used for archival purposes & you can debug straight >>>> >from .o/.dwos for interactive/iterative development. >>>> >>>>> In that case, it seems more likely that a separate tool might suffice. >>>> agreed: if to continue the work on this then it makes sense to >>>> do it as separate tool. Make it fast enough. And if th...

...eractive > developers wouldn't > >>>>> necessarily be using this feature. Makes sense - similar to > dsymutil > >>>>> and dwp, mostly used for archival purposes & you can debug > straight > >>>> >from .o/.dwos for interactive/iterative development. > >>>> > >>>>> In that case, it seems more likely that a separate tool > might suffice. > >>>> agreed: if to continue the work on this then it makes sense to > >>>> do it as...

>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

...velopers >>> wouldn't >>> >>>>> necessarily be using this feature. Makes sense - similar to >>> dsymutil >>> >>>>> and dwp, mostly used for archival purposes & you can debug straight >>> >>>> >from .o/.dwos for interactive/iterative development. >>> >>>> >>> >>>>> In that case, it seems more likely that a separate tool might >>> suffice. >>> >>>> agreed: if to continue the work on this then it makes sense to >>> >&g...

...interactive developers wouldn't >>>> >>>>> necessarily be using this feature. Makes sense - similar to dsymutil >>>> >>>>> and dwp, mostly used for archival purposes & you can debug straight >>>> >>>> >from .o/.dwos for interactive/iterative development. >>>> >>>> >>>> >>>>> In that case, it seems more likely that a separate tool might suffice. >>>> >>>> agreed: if to continue the work on this then it makes sense to >>>> &gt...