This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LTO] LTO breaks if debug info is stripped from object files


Daniel Jacobowitz wrote:
> On Fri, Nov 16, 2007 at 03:03:15PM -0500, Diego Novillo wrote:
>> I'm not sure if it's intended, but I don't think it's desirable.  The 
>> information needed to do LTO optimizations should be independent from the 
>> debugging information.
> 
> FWIW, I disagree - not least because this makes GCC much more sensitive
> to the correctness of its debugging output!

Right.

In these discussions about DWARF-for-LTO, it's important to remember
several things that went into the design.  Some of these things have
changed, and so maybe things about DWARF-for-LTO should change too, but
they're still relevant for perspective.  Here are three of the goals:

1. One goal was a compiler-independent (or, at least,
GCC-version-independent) representation.  We gave up on that for
function-body representations, but the original LTO design (as
circulated back in late 2005) had us designing a compiler-independent
representation of expressions, too, with the goal of enabling non-LTO
uses (such as IDEs, code-analysis tools, etc.).

2. Another goal was not to make .o files larger by duplicating the debug
information for LTO.  LTO needs names and types of functions; so does DWARF.

3. Finally, we felt DWARF was already designed for some combination of
compactness and ability to skip about in the representation (rather than
having to un-serialize everything to get any information) so it seemed a
plausible representation format.

4. As Daniel says, a secondary goal was to improve GCC's debug
information by making its correctness imperative for LTO.  If all we
care about is performance, that might not matter much -- but as per
recent discussions on this list, many users care a lot about debugging
information and the debugging experience, so improving debug information
quality seems beneficial.  For example, capturing GNU attributes in
debug information for LTO will also debuggers and other tools that peer
at debug information to have a more accurate view of the program.

If we decide that we want to put the LTO declarative information in a
separate section, we might well be able to do better than DWARF.  I
don't feel like we know enough yet to do that.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]