Hi Jeff, On Fri, 2020-06-05 at 10:07 -0600, Jeff Law wrote: > On Fri, 2020-06-05 at 15:56 +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > > One issue I am concerned about here is debuginfo quality. GCC produced > > pretty bad debuginfo with LTO in older versions. The EarlyDebug work > > did make it usable. And we needed some work on the DARF consumers to > > correctly process GCC 10 LTO produced DWARF (I actually have two small > > patches for elfutils pending so it correctly parses the cross CU- > > references GCC 10 LTO now produces). > > > > I don't know if anybody did any analysis on llvm LTO produced > > debuginfo. In the past it was observed that llvm doesn't do VTA (Var > > Tracking Assignments) that is default in GCC. And VTA is really > > important for debugging and performance/tracing tools like systemtap. > > So even without LTO I am concerned about the observability of llvm > > generated binaries. > > And these are reasonable concerns (even more so in an LTO world and I expect I'll > be spending most of my summer poking at debuginfo stuff for GCC LTO :-). > > IMHO this is one of the issues an upstream project needs to evaluate for their > toolchain choice -- no different than performance, diagnostics, sanitizer > support, plug-in support, etc etc. The level of observability needed by any > particular upstream project can vary. ie, the kernel may well have different > needs than the Ruby interpreter. I think you place too much faith in upstream and give Fedora and Fedora packagers not enough credit for creating a well integrated distribution. For Fedora it is important that what we ship is observable by our users. We, together with our users, sometimes need to debug, trace or do performance analysis on the binaries as we ship them. Some upstream projects don't care about that at all. They will happily tell their users to just rebuild with some other tools/optimizations/etc. Or just rebuild their whole world with some sanitizers enabled. So then an upstream developer might prefer a different toolchain, simply because they personally would rebuild the whole world with it. In such cases Fedora should not simply switch to a non-default system compiler. > I have not done any evaluation of LLVM's debug info. I would not be surprised if > GCC is generally better, particularly with Alex's work over the last couple > years. But again, I think the upstream project is in the best position to > determine how to balance this against the other factors in toolchain selection. GCC's is certainly better, it has much better coverage. That doesn't mean that LLVM's debuginfo is invalid, but it is less useful. At some point the kernel accidentially disabled VTA and it made the kernel a lot less observable by systemtap for example. And even if it is correct it might still not be fully supported by all our tools. For example clang used to default to not generate .debug_aranges, which is valid, but means a DWARF consumer needs to construct its own aranges table by reading the all the CUs. elfutils doesn't support that, and so some address/line lookups simply fail with clang generated binaries. I could cerainly add support for missing .debug_aranges, but there is so much more to do (luckily I could convince them to switch the default to generate .debug_aranges, at least for rust code). In general when someone reports an issue with an elfutils or valgrind based tool and it is against code not compiled with the default gcc toolchain I simply have to tell people to please use the system compiler. There are just not enough time to also try to resolve any debuginfo issues because people use an alternative toolchain. So I like this proposal to be a bit more strict in when it is OK to not use the system toolchain. Just deferring to upstream preference seems too weak. If upstream supports building with gcc, but some upstream developers have a preference for using clang, I would prefer to make it clear that the Fedora package should keep using gcc. We simply don't have the resources for all other tools to have to deal with another toolchain. Thanks, 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
