On Fri, 2020-06-05 at 15:56 +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: > Send devel mailing list submissions to > devel@xxxxxxxxxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > devel-request@xxxxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > devel-owner@xxxxxxxxxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > Today's Topics: > > 1. Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change > (Mark Wielaard) > 2. Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change > (Josh Boyer) > 3. Re: Fedora 33 System-Wide Change proposal: swap on zram > (Igor Raits) > 4. Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change > (Jeff Law) > > > ---------------------------------------------------------------------- > > Date: Fri, 05 Jun 2020 17:47:51 +0200 > From: Mark Wielaard <mjw@xxxxxxxxxxxxxxxxx> > Subject: Re: Fedora 33 System-Wide Change proposal: CompilerPolicy > Change > To: law@xxxxxxxxxx, Development discussions related to Fedora > <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Message-ID: > <3c8151c120d43cfa33d1dae11ba1c2b4f6e16be9.camel@xxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > On Fri, 2020-06-05 at 09:25 -0600, Jeff Law wrote: > > The LTO bytecode streams do not survive past any given package build. ie, > > they > > are used within the build, then discarded. They're not supposed to show up > > in > > any installed libraries. > > > > Thus the fact that the two compilers use totally different LTO > > representations > > (and always will) is a non-issue here. > > 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 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. 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
