Hi, Replying since I am mentioned by name in this proposal and it seems to argue for removing a feature I am currently working on to make sure it works correctly with GCC11 if it switches to producing DWARF5 by default. The proposal seems based on some misunderstandings. On Thu, Sep 24, 2020 at 11:59:44AM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DebugInfoStandardization > > == Summary == > Fedora 18 implemented [[Features/DwarfCompressor]]. As the format did > not get widespread and the tool is not much maintained As others pointed out dwz is widely used. It is used by almost every distro in some form and even freedesktop.org flatpaks use dwz for their debuginfo. The upstream project is actively maintained. Even though there are just 3 committers (including me) the project is still seeing ~2.5 commits a week (about 130 in a year). > There exist several methods > how to make the *-debuginfo.rpms at least a bit smaller. Fedora 18 > started using DWZ tool (from [[Features/DwarfCompressor]]) while > [https://gcc.gnu.org/pipermail/gcc-patches/2008-August/246281.html > Google implemented] the same goal in a different way called > -fdebug-types-section. Note that these methods are not in conflict. Both started out as GNU extensions but have been standardized since. > so its support is missing in tools like > [https://lldb.llvm.org/ LLDB], But you have been maintaining an out of tree patch for several years to support partial units and supplemental files (both of which dwz produces and are now standard DWARF). It would be good if you upstreamed those patches. > [[llvm-dwarfdumphttps://llvm.org/docs/CommandGuide/llvm-dwarfdump.html|llvm-dwarfdump]] Note that normal dwarfdump as shipped with libdwarf-tools does support both partial units and supplemental files (you do need to provide the alt file with --file-tied=/path/to/alt-file which probably should be done automatically). > or binutils readelf. binutils readelf is used as the main tool in the dwz testsuite. It certainly supports both partial units and supplemental files. Also note the the -wK (=follow-links) option [it isn't on by default, maybe it should] that resolves alt links. I don't know of any other tool which doesn't support either partial units or supplemental files, since both are (now) standard DWARF. > * DWZ disadvantage: DWZ requires 8x times more complicated (LoC count) > support in consumers than -fdebug-types-section. I have worked on support for both in various consumers and didn't find one method more difficult to support than the other. Maybe debug-types was actually more difficult. Because the representation changed from separate section in DWARF4, to intermingled with other .debug_info units in DWARF5. Making supporting objects that contained mixed versions a bit of a pain. > * DWZ disadvantage: DWZ cannot update LLVM .debug_names index which > can be generated only by clang (it cannot be regenerated later for > DWZ-compressed file) dwz does support .gdb_index, the pre-standardized DWARF5 .debug_names variant. gdb hasn't switched to supporting .debug_names yet and .gdb_index does work with DWARF5. I don't think the gdb maintainers would mind you adding .debug_names support if you believe it to be better than .gdb_index. > * DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has > been blocking DWARF-5 for Fedora for 3.5 years and only after I have > now proposed to drop DWZ Mark Wielaard has started porting DWZ to > DWARF-5. I have worked on DWARF5 support for various projects for the last couple of years. Since it looks like GCC11 might switch to DWARF5 by default I started added DWARF5 support to dwz. I started that earlier this month after we had a discussion on DWARF5 at the virtual GNU Tools Cauldron, I didn't know you were proposing to drop DWZ in Fedora. You can follow the progress on the dwz mailinglist. https://sourceware.org/pipermail/dwz/current/ > This proposed DWARF format was originally submitted already for Fedora > 18 as [[Features/DebugTypesSections]]. Note that it isn't a different format, just an additional way to represent some parts of DWARF. I have also proposed gcc would emit debug-types by default and even discussed it two times at the GNU Tools Cauldron. But I couldn't get buy-in from the GCC hackers that it is a good idea. And I do think they have a point. It is a not very flexible design with a somewhat high overhead (somewhat reduced in DWARF5 by not making it part of a separate section). If you think it really is a good idea to use them more broadly and by default then you should probably start by getting consensus from the upstream gcc developers that it should be enabled by default. I don't think it is in conflict with also using dwz. But it will probably require some extra work. Cheers, Mark _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
