On Sun, Jul 27, 2008 at 7:18 PM, Mark Mitchell <[EMAIL PROTECTED]> 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.
