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: Alexandre Oliva <aoliva at redhat 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>, Richard Guenther <richard dot guenther at gmail dot com>, "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: Tue, 29 Jul 2008 15:46:39 -0300
- Subject: Re: lto gimple types and debug info
- References: <488A6E70.2060708@codesourcery.com> <200807261748.m6QHmh0O027966@makai.watson.ibm.com> <488CADFB.4020007@codesourcery.com>
On Jul 27, 2008, Mark Mitchell <mark@codesourcery.com> wrote:
> 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!
+1
> 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.
Or construct the location lists using DW_OP_piece et al to denote the
location of each fragment of the object.
> 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?
no, we don't do this with SRA, but I designed VTA so that it would be
trivial to annotate the scalarization assignments, which would then be
maintained all the way up to var-tracking, where it could be turned
into debug info for the separate pieces.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ÂSÃ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}