This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lto gimple types and debug info


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
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]