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?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
