search for: dwarflink

...ODR) |  63.6         | > | Clang (DWARF linker) | 200.6         | > +-----------------------------+---------------+ > > Output size - Game package (MB): > +-----------------------------+------+ > | Category                | GC 1 | > +-----------------------------+------+ > | DWARFLinker (total)         |  696 | > | DWARFLinker (DWARF*)        |  429 | > | DWARFLinker (other)         |  267 | > | DWARFLinker no ODR (total)  |  753 | > | DWARFLinker no ODR (DWARF*) |  485 | > | DWARFLinker no ODR (other)  |  268 | > +-----------------------------+------+ > &gt...

...ARF linker) | 200.6 | >> +-----------------------------+---------------+ >> >> Output size - Game package (MB): >> +-----------------------------+------+ >> | Category | GC 1 | >> +-----------------------------+------+ >> | DWARFLinker (total) | 696 | >> | DWARFLinker (DWARF*) | 429 | >> | DWARFLinker (other) | 267 | >> | DWARFLinker no ODR (total) | 753 | >> | DWARFLinker no ODR (DWARF*) | 485 | >> | DWARFLinker no ODR (other) | 268 | >> +----------------------...

...| | Game (DWARF linker, no ODR) | 63.6 | | Clang (DWARF linker) | 200.6 | +-----------------------------+---------------+ Output size - Game package (MB): +-----------------------------+------+ | Category | GC 1 | +-----------------------------+------+ | DWARFLinker (total) | 696 | | DWARFLinker (DWARF*) | 429 | | DWARFLinker (other) | 267 | | DWARFLinker no ODR (total) | 753 | | DWARFLinker no ODR (DWARF*) | 485 | | DWARFLinker no ODR (other) | 268 | +-----------------------------+------+ Output size - Clang (MB): +----------...

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

...6 | > | Clang (DWARF linker) | 200.6 | > +-----------------------------+---------------+ > > Output size - Game package (MB): > +-----------------------------+------+ > | Category | GC 1 | > +-----------------------------+------+ > | DWARFLinker (total) | 696 | > | DWARFLinker (DWARF*) | 429 | > | DWARFLinker (other) | 267 | > | DWARFLinker no ODR (total) | 753 | > | DWARFLinker no ODR (DWARF*) | 485 | > | DWARFLinker no ODR (other) | 268 | > +-----------------------------+------+ > &gt...

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 and uses DWARFLinker library > to create a new (dwarf-linked) separated-debug file, that doesn't depend on DWO/DWP files. The three goals which you`ve described are our far goals. Indeed, the be...

....6         | >> +-----------------------------+---------------+ >> >> Output size - Game package (MB): >> +-----------------------------+------+ >> | Category                    | GC 1 | >> +-----------------------------+------+ >> | DWARFLinker (total)         |  696 | >> | DWARFLinker (DWARF*)        |  429 | >> | DWARFLinker (other)         |  267 | >> | DWARFLinker no ODR (total)  |  753 | >> | DWARFLinker no ODR (DWARF*) |  485 | >> | DWARFLinker no ODR (other)  |  268 | >>...

...ce:   OVERVIEW: A tool for optimizing debug info located in the built binary.   USAGE: llvm-dwarfutil [options] input output   OPTIONS: (Apndx E) ====================================================================== Implementation notes: 1. Removing obsolete debug info would be done using DWARFLinker llvm library. 2. Data types deduplication would be done using DWARFLinker llvm library. 3. Accelerator/index tables would be generated using DWARFLinker llvm library. 4. Interface of DWARFLinker library would be changed in such way that it    would be possible to switch on/off various stage...

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. I'm not surprised that the same can't be said for other sections, but I'm also pl...

...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) Assuming the proposal is accepted, this should be introduced > piecemeal into LLVM from the beginning as it is developed, rather than > having a separate step 4 in the roadmap. > 2) The default tombstone values used for dead debug...

...by me) > to use more of lld's infrastructure to be more efficient (it's current > object reading/writing logic is using LLVM's libObject and MCStreamer, > which is a bit inefficient for a very content-unaware linking process) > and then maybe that could be taught to use DwarfLinker as a library to > optionally do DWARF-aware linking depending on the users time/space > tradeoff desires. Still benefiting from any improvements to the > underlying DwarfLinker library (at which point that would be shared > between llvm-dsymutil, llvm-dwz, and llvm-dwp). > >...

...uced size of debug info allows tools to work faster and to require less memory. drawbacks and not implemented features: 1. linking time is increased(755%). The --gc-debuginfo option is off by default. So it would affect only those who need it and explicitly specified it. I think the current DWARFLinker code could be optimized more to improve performance results. 2. Support of type units. That could be implemented further. 3. DWARF5. Current DWARFEmitter/DWARFStreamer has an implementation for DWARF generation, which does not support DWARF5(only debug_names table). At the same time, the...

...he patch attached. The original review suggested that I try to use the AsmPrinter and many of its associated classes to generate the DWARF. I attempted to do so and the AsmPrinter version is in lib/CodeGen/DwarfGenerator.{h,cpp} in the patch attached. This AsmPrinter based code steals code from the DwarfLinker.cpp. > > > > I am having trouble getting things to work with the AsmPrinter. I was able to get simple DWARF to be emitted with the AsmPrinter version of the DWARF generator with code like: > > > initLLVM(); > DwarfGen DG; > Triple Triple("x86_64--&quo...

...39;s infrastructure to >> be more efficient (it's current object reading/writing logic is >> using LLVM's libObject and MCStreamer, which is a bit inefficient >> for a very content-unaware linking process) and then maybe that >> could be taught to use DwarfLinker as a library to optionally do >> DWARF-aware linking depending on the users time/space tradeoff >> desires. Still benefiting from any improvements to the underlying >> DwarfLinker library (at which point that would be shared between >> llvm-dsymutil, llvm-d...

...fficient (it's >>> current object reading/writing logic is using LLVM's >>> libObject and MCStreamer, which is a bit inefficient for a >>> very content-unaware linking process) and then maybe that >>> could be taught to use DwarfLinker as a library to >>> optionally do DWARF-aware linking depending on the users >>> time/space tradeoff desires. Still benefiting from any >>> improvements to the underlying DwarfLinker library (at which >>> point that would be shar...

...with non-fragmented DWARF). >>>>>>>>>> That idea is for the tool which works the same way as dsymutil ODR. >>>>>>>>>> >>>>>>>>>> I will shortly describe the idea of making DWARF be easier processed by dsymutil/DWARFLinker: >>>>>>>>>> >>>>>>>>>> The idea is to have only one "type table" per object file(special section .debug_types_table). >>>>>>>>>> This "type table" would contain all types. >>>&gt...

...F). >>>>>>>>>>>> That idea is for the tool which works the same way as dsymutil ODR. >>>>>>>>>>>> >>>>>>>>>>>> I will shortly describe the idea of making DWARF be easier processed by dsymutil/DWARFLinker: >>>>>>>>>>>> >>>>>>>>>>>> The idea is to have only one "type table" per object file(special section .debug_types_table). >>>>>>>>>>>> This "type table" would contain al...

...it should work with non-fragmented DWARF). >> >> >> >> That idea is for the tool which works the same way as dsymutil ODR. >> >> >> >> >> >> >> >> I will shortly describe the idea of making DWARF be easier processed by dsymutil/DWARFLinker: >> >> >> >> >> >> >> >> The idea is to have only one "type table" per object file(special section .debug_types_table). >> >> >> >> This "type table" would contain all types. >> >> >> &gt...

...plied to linked executable it should work with non-fragmented DWARF). >> >> >> That idea is for the tool which works the same way as dsymutil ODR. >> >> >> >> >> >> I will shortly describe the idea of making DWARF be easier processed by dsymutil/DWARFLinker: >> >> >> >> >> >> The idea is to have only one "type table" per object file(special section .debug_types_table). >> >> >> This "type table" would contain all types. >> >> >> There could be a special type...

...>>>> That idea is for the tool which works the same way as > dsymutil ODR. > >>>>>>>>>>>> > >>>>>>>>>>>> I will shortly describe the idea of making DWARF be > easier processed by dsymutil/DWARFLinker: > >>>>>>>>>>>> > >>>>>>>>>>>> The idea is to have only one "type table" per object > file(special section .debug_types_table). > >>>>>>>>>>>> This &qu...