This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: lto gimple types and debug info
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Mark Mitchell" <mark at codesourcery dot com>
- Cc: "David Edelsohn" <dje at watson dot ibm dot com>, "Kenneth Zadeck" <zadeck at naturalbridge dot com>, "GCC Development" <gcc at gcc dot gnu dot org>, "Diego Novillo" <dnovillo at google dot com>, "Hubicha, Jan" <jh at suse dot cz>, "Taylor, Ian Lance" <iant at google dot com>, "Ollie Wild" <aaw at google dot com>, "Maddox, Bill" <maddox at google dot com>, jason at redhat dot com, "Rafael Espindola" <espindola at google dot com>
- Date: Sun, 27 Jul 2008 20:09:42 +0200
- Subject: Re: lto gimple types and debug info
- References: <488A6E70.2060708@codesourcery.com> <200807261748.m6QHmh0O027966@makai.watson.ibm.com> <488CADFB.4020007@codesourcery.com>
On Sun, Jul 27, 2008 at 7:18 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> David Edelsohn wrote:
>
>> I do not expect LTO (or WHOPR) to work on AIX -- at least not
>> without a lot of work on wrappers around the AIX linker. However, I do
>> not understand why enhancing GCC to support LTO -- when GCC is run without
>> enabling LTO -- requires locking GCC completely into DWARF debugging.
>
> I agree that, at least in principle, it should be possible to emit the debug
> info (whether the format is DWARF, Stabs, etc.) once. So, I don't see a
> reason that this makes us a DWARF-only compiler either.
>
> Others have raised the issue of types which are fundamentally transformed by
> the compiler (such as by removing fields). I think that such opportunities
> are going to be relatively rare; the global "struct Window" object in a GUI
> library full of functions taking "struct Window *" parameters probably isn't
> optimizable in this way. But there will be situations where this is
> possible and profitable of course.
>
> In that case, I'm not sure that *type* ought to be modified at all, from the
> debug perspective. To the extent there's still an object of type "struct X"
> around, it's type is still what it was. And other things you might do in a
> debugger, like ask "What member functions does class X have?", have the same
> answer no matter the layout chosen by the compiler, including throwing out
> half the fields and leaving the rest in random registers. For that matter,
> "print sizeof(X)" should print the same value when debugging optimized code
> as when debugging unoptimized code, even if the compiler has optimized X
> away to an empty structure!
>
> There are other things we could do, like mark the *variables* of type X
> (rather than the type) as having no location, so that you can't print/modify
> objects that have been optimized in this way. That reflects more accurately
> the user's view of what has happened; it's not that the type itself is
> different as much as it is that objects of the type are hard to view.
>
> You could also add a marker to the type that says "optimized madly; debugger
> should proceed with caution" -- and you could do that without reloading and
> rewriting the type information. For example, when generating the original
> type debug info, emit a relocation against "X_optimized_madly" and then
> providing an approprivate value for the symbol at link time.
>
> I'm curious what we do with SRA at the moment. This is the same sort of
> problem; do we have any solutions at present?
We generate variables with names like x$y for struct { int y; } x; - in theory
the debugger could "magically" associate a print x.y with x$y. But of course
there is no way to express this in the DWARF.
Richard.