This is the mail archive of the
mailing list for the GCC project.
debugging info considered harmful to lto.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: gcc <gcc at gcc dot gnu dot org>, "Hubicha, Jan" <jh at suse dot cz>, Ian Lance Taylor <iant at google dot com>, "Park, Seongbae" <seongbae dot park at gmail dot com>, Mark Mitchell <mark at codesourcery dot com>, dan at debian dot org, jason at redhat dot com, "Berlin, Daniel" <dberlin at dberlin dot org>
- Date: Sun, 22 Jul 2007 19:37:43 -0400
- Subject: debugging info considered harmful to lto.
At the summit, I discovered two things about the internal representation
of debugging information:
1) According to Honza, the instances of the BLOCK tree type take 30% of
the space in a compilation.
2) The BLOCKS structure is linked in a way so that the blocks for one
function link to the blocks of other functions.
These two facts conspire to create a big problem for GCC/LTO, especially
when we progress to trying to compile very large programs. Unlike many
other essential parts of gcc, the current representation of debugging
information is not one that can be divided into moderate sized pieces
that can be processed independently.
Honza's last lto patch "solves" the problem in the very short term by
simply creating a single BLOCK for each function. This provides enough
information to allow our testing to continue, but means that no useful
debugging information will be generated. This is not acceptable in
even the medium term, but it allows the problem to be deferred while
Mark and I get the basics of reading and writing gimple working.
I find it somewhat surprising that we need so many blocks. My
experience is that in real programs few blocks actually have any local
declarations and it appears that we do not bother to get rid of the
blocks that have no local decls. However the biggest problem for lto
is that when a procedure is inlined, the set of blocks for the inlined
function is copied and the new copies have a cross link to the original
version. It would help a lot if that pointer could be replaced with
something like a pointer to a function decl and the dfs number of the
block in the original function. I do not know the semantics of what is
needed by the debuggers, but some representation where each function can
be managed as a separate unit is going to be required to process large
Suggestions are welcome, but volunteers willing to attack this problem
are truly needed. I do not think that anyone would take lto seriously
if we cannot support debugging; only toy compilers do not have debugging.