Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Fri, 02 Oct 2020 18:11:45 +0200, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 15:58:51 +0200, Stephen John Smoogen wrote: > > On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil > > wrote: > > > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > > > > = What I am NOT working on > > > [...] > > > > - Any other tool, project not mentioned above or other > > > > native toolchains like golang, rust, clang/llvm or ocaml. > > > > I expect those to simply keep producing DWARF4. > > > > > > So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. > > > Despite clang supports DWARF-5 better and for a longer time than GCC. > > > > I did not take it to mean that. I took it to mean that he isn't going to > > tell other groups what to work on which a change request seems to have > > become. He instead expects them to keep doing what they are doing if they > > want versus getting forced to do what he is working on. > > Currently on files built by clang -gdwarf-5 DWZ will fail: > dwz: ./usr/lib64/libmatrix_client.so.0.3.1-0.3.1-2.fc34.x86_64.debug: > Unknown debugging section .debug_addr > > Which is fine as the file just does not get optimized. But that results in rpm > size bigger for clang-built binaries by 31.23% as -fdebug-types-section is not > used. If -fdebug-types-section was used for clang-built binaries DWZ would > fail a similar way but the size increase would be "just" by 6.78%. I had a wrong idea. For clang -flto the option -fdebug-types-section no longer makes sense as clang produces direct DW_TAG_class references (DW_FORM_ref4). So DWZ cannot optimize clang output better, DWZ makes sense only for GCC, not clang. (A bit, DWZ can still find slightly more optimal DW_FORM_* variants than clang, I will check if it cannot be fixed in clang.) Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Wed, 30 Sep 2020 15:58:51 +0200, Stephen John Smoogen wrote: > On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil > wrote: > > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > > > = What I am NOT working on > > [...] > > > - Any other tool, project not mentioned above or other > > > native toolchains like golang, rust, clang/llvm or ocaml. > > > I expect those to simply keep producing DWARF4. > > > > So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. > > Despite clang supports DWARF-5 better and for a longer time than GCC. > > I did not take it to mean that. I took it to mean that he isn't going to > tell other groups what to work on which a change request seems to have > become. He instead expects them to keep doing what they are doing if they > want versus getting forced to do what he is working on. Currently on files built by clang -gdwarf-5 DWZ will fail: dwz: ./usr/lib64/libmatrix_client.so.0.3.1-0.3.1-2.fc34.x86_64.debug: Unknown debugging section .debug_addr Which is fine as the file just does not get optimized. But that results in rpm size bigger for clang-built binaries by 31.23% as -fdebug-types-section is not used. If -fdebug-types-section was used for clang-built binaries DWZ would fail a similar way but the size increase would be "just" by 6.78%. I do not find there much a difference, just stating. (These percents are relative to total *-debuginfo.rpm size, not to total distribution size.) Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On 9/30/20 6:50 AM, Mark Wielaard wrote: Hi Neal, On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote: For the record, Mark has started implementing DWARF-5 support in dwz: https://sourceware.org/git/?p=dwz.git;a=log I think I would rather like to see a Change proposal to switch to DWARF-5 for Fedora 34, especially since it looks like dwz will be ready for it. That is indeed my goal, but I wasn't planning on filing a specific Change Proposal for it. First because as you observed in the past we did some of these debuginfo things Fedora first and then it took years (!) for some of the default settings we had changed and helper scripts to make it upstream. So I am concentrating on getting everything ready upstream first before making and proposing any changes for Fedora. Secondly I am hoping that because of the first point the GCC11 for Fedora 34 Change Proposal will simply say "-gdwarf-5 is now the default". In that change proposal can you add a sentence or two in the proposal indicating that I will do a test rawhide build with gcc-11 with dwarf5 on by default? My worry is that once Aldy/Andrew's Ranger work has finished that I'll forget the need for dwarf5 testing. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > > = What I am NOT working on > [...] > > - Any other tool, project not mentioned above or other > > native toolchains like golang, rust, clang/llvm or ocaml. > > I expect those to simply keep producing DWARF4. > > So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. > Despite clang supports DWARF-5 better and for a longer time than GCC. > > I did not take it to mean that. I took it to mean that he isn't going to tell other groups what to work on which a change request seems to have become. He instead expects them to keep doing what they are doing if they want versus getting forced to do what he is working on. > > Jan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote: > = What I am NOT working on [...] > - Any other tool, project not mentioned above or other > native toolchains like golang, rust, clang/llvm or ocaml. > I expect those to simply keep producing DWARF4. So because of a DWZ deficiency you want to keep DWARF-5 in clang disabled. Despite clang supports DWARF-5 better and for a longer time than GCC. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Switching to DWARF5 default for GCC11 (and the default Fedora 34 toolchain)
Hi Neal, On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote: > For the record, Mark has started implementing DWARF-5 support in dwz: > https://sourceware.org/git/?p=dwz.git;a=log > > I think I would rather like to see a Change proposal to switch to > DWARF-5 for Fedora 34, especially since it looks like dwz will be > ready for it. That is indeed my goal, but I wasn't planning on filing a specific Change Proposal for it. First because as you observed in the past we did some of these debuginfo things Fedora first and then it took years (!) for some of the default settings we had changed and helper scripts to make it upstream. So I am concentrating on getting everything ready upstream first before making and proposing any changes for Fedora. Secondly I am hoping that because of the first point the GCC11 for Fedora 34 Change Proposal will simply say "-gdwarf-5 is now the default". Lastly, and sadly, I find the whole Fedora change proposal debates extremely hostile. They often seem to quickly result in people attacking you because you made a choice to spend time to work on A and not their favorite feature B, and if they cannot have feature B then you should also not spend any more time on A. So I am happy to describe the work I am doing to try to get DWARF5 the default for GCC11 and by extension for the Fedora 34 default toolchain, but I will mainly do that work upstream and then see whether it is all ready on time to enable it for Fedora 34. But I am not interested in a heated debate on how I should prioritize my time and energy. = Why DWARF5 for GCC? - A couple of new tags and attributes make it easier/more accurate to describe some of the newer language features (although most were already covered by various GNU extensions) - A lot of GNU extensions to DWARF4 have been standardized in DWARF5. By adopting the standardized variant alternative toolchains will hopefully find it easier to support these features. - The representation of various data structures in DWARF5 is much more efficient causing a 25% on-disk size reduction (before any other compression method) for the .debug sections: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553527.html = DWARF5 for the (extended) GNU toolchain - binutils (gas) is responsible for turning part of the assembly produced by the compiler into a line table (.debug_line) and the linker sometimes reads parts of the DWARF (for example when producing warnings about where a symbol was defined). The just released binutils 2.35.1 should have all fixes necessary to support DWARF5. - gcc needs to use the new gas features. Jakub has a patch (not committed yet): https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553992.html - gdb seems ready except for one corner case with C++ static member variables in classes. This is because in DWARF5 these are represented not as variables, which might be optimized away when not used. In this case gcc probably shouldn't optimize out the unused variables (or gdb should not depend on being able to show optimized out static member variables). Ongoing debate how to resolve this: https://sourceware.org/bugzilla/show_bug.cgi?id=26525 https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html - The just released elfutils 0.181 seems to have all needed support, which should cover systemtap, dwarves, perf, systemd, libabigail. More testing ongoing. - For valgrind I initially wanted to switch the DWARF reader to an external helper program based on elfutils libdw. But to get a solution faster I will tweak the internal reader to deal with just the minimal DWARF5 as generated by gcc for now. I haven't started on this yet. = DWARF5 for the (Fedora) packaging tools - rpm debugedit has patches to support DWARF5 but we have to make sure they have testcases to work with gcc: http://lists.rpm.org/pipermail/rpm-maint/2020-August/014833.html - dwz is seeing active work towards supporting DWARF5: https://sourceware.org/pipermail/dwz/2020q3/000668.html I am hoping that by end of next week we have generic support. That might not do optimal compression yet and will probably need lots of testing (and bug fixing). = What I am NOT working on - We'll keep using .gdb_index for now, moving to .debug_names only when that is ready in gdb: https://sourceware.org/pipermail/gdb/2020-September/048879.html - Optional DWARF5 features like debug-types, forms, operations or index tables only used for split-dwarf by GCC (e.g. DW_FORM_strx, DW_FORM_addrx, DW_FORM_loclistx, DW_FORM_rnglistx, DW_OP_addrx, DW_OP_constx). - Any other tool, project not mentioned above or other native toolchains like golang, rust, clang/llvm or ocaml. I expect those to simply keep producing DWARF4. That doesn't mean I won't help with any of the above if others propose to do that work for the various pieces of the toolchain and packaging, but I currently don't have time for it and I
