Re: lto gimple types and debug info

["Daniel Berlin" <dberlin at dberlin dot org>]

On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Daniel Berlin wrote:
>
>>> I agree that, at least in principle, it should be possible to emit the
>>> debug
>>> info (whether the format is DWARF, Stabs, etc.) once.
>>
>> No, you can't.
>> You would at least have to emit the variables separate from the types
>> (IE emit debug info twice).
>
> Yes, of course; that's what everyone is talking about, I think.  "Emit" here
> may also mean "cache in memory some place", rather than "write to a file".
>  It could mean, for example, fill in the data structures we already use for
> types in dwarf2out.c early, and then throw away the front-end type
> information
Okay, then let us go through the options, and you tell me which you
are suggesting:

If you assume LTO does not have access to the front ends, your options
look something like this:

When you first compile each file:
  Emit type debug info
  Emit LTO

When you LTO them all together
  Do LTO
  Emit variable debug info

Under this option, "Emit variable info" requires being able to
reference the types.  If you've lowered the types,  this is quite
problematic.  So either you get to store label names for the already
output type debug info with the variables (so you can still reference
the type you output properly when you read it back in).  This is
fairly fragile, to be honest.
Another downside of this is that you can't eliminate duplicate types
between units because you don't know which types are really the same
in the debug info. You have to let the

Another option is:

When you first compile each file:
  Emit type debug info
  Emit partial variable debug info (IE add pointers to outputted types
but not to locations)
  Emit LTO

When you LTO them all together:
  Do LTO
  Parse and update variable debug info to have locations
  Emit variable debug info

This requires parsing the debug info (in some format, be it DWARF or
some generic format we've made up) so that you can update the variable
info's location.
As a plus, you can easily update the types where you need to.
Unlike the first option, because you understand the debug info, you
can now remove all the duplicate types between units without having to
have the linker do it for you.

Unless  you link in every single frontend to LTO1 (Or move a lot to
the middle end), there is no way to do the following:

When you first compile each file:
  Emit LTO

When you LTO them all together:
  Emit type debug info
  Do LTO
  Emit variable debug info

If you don't want to link the frontends, you could also get away with
moving a lot of junk to the middle end (everything from being able to
distinguish between class and struct to namespaces, the context of
lexical blocks) because debug info outputting uses language specific
nodes all over the place right now.

Unless i've missed something, our least fragile and IMHO, best option
requires parsing back in debug info.
It is certainly *possible* to get debug info without parsing the debug
info back in.
Then again, I also don't see what the big deal about adding a debug
info parser is.

It's not like they are all that large.

[dannyb@tallac:/home/dannyb/util/debuginfo]> wc -l bytereader.*
bytereader-inl.h dwarf2enums.h dwarf2reader*
   40 bytereader.cc
  110 bytereader.h
  118 bytereader-inl.h
  465 dwarf2enums.h
  797 dwarf2reader.cc
  373 dwarf2reader.h
 1903 total

(This includes both a callback style reader that simply hands you
thinks you tell it to, as well as something that can read back into a
format much like we use during debug info output)