On Fri, 2020-06-05 at 23:04 +0200, Mark Wielaard wrote: > 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 put faith in both the upstreams and packagers to do the right thing for their project. Right now Fedora policy does exactly the opposite by forcing everyone to use GCC rather than making an informed, per project, decision. If an upstream has decided that debug-ability isn't a priority, then, the packager for Fedora has to decide if the project is even really suitable for Fedora and take on a degree of responsibility for the package. > > > 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. I'm well aware of the kernels' disabling VTA, it was done in response to a codegen bug that was triggered by the VTA changes. Sadly the kernel's response was a bit drastic. But that's water under the bridge. > > 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. All valid concerns. THe way to respond when something like this comes up is something like: 1. Analyze the issue and report back what was found. 2. Create bugs/rfes to track additional work that may need to be performed 3. Give them possible workarounds by using different tools. That should in turn flow to the uptream package and becomes part of the feedback loop they use to determine what toolchain they should be using. Its no different than a bug or missing feature -- the upstream project gets to decide if the issue is significant enough to warrant changing recommendations or waiting for the tools they're using to catch up. Simply punting is no longer a real option IMHO. > > 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. It's probably a given that for a sufficiently large upstream that there will be some in that upstream that want to use GCC and others that will want to use Clang/LLVM. The fact that individual upstream developers want to use compiler X and others want to use compiler Y isn't the deciding factor -- what is the upstream's project's preference/stance. Jeff _______________________________________________ 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
