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: "David Edelsohn" <dje at watson dot ibm dot com>
- Cc: "Mark Mitchell" <mark at codesourcery 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: Sat, 26 Jul 2008 19:55:39 +0200
- Subject: Re: lto gimple types and debug info
- References: <488A6E70.2060708@codesourcery.com> <200807261748.m6QHmh0O027966@makai.watson.ibm.com>
On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <dje@watson.ibm.com> wrote:
> Kenny> 2) Generate the debugging for the types early, and then add an
> Kenny> interface that would parse and regenerate the debugging info with
> Kenny> the changes. It is quite likely that this would lock gcc
> Kenny> completely into dwarf, but that appears to only be a problem for
> Kenny> AIX at this point, so that may not be that much of a problem.
>
> Mark> This is the approach I would suggest. Dump out the debug info for types
> Mark> before you throw away all the information, and then leave it aside.
>
> 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.
>
> The emails propose generating the debugging for types early, which
> has no dependency on DWARF. If no LTO IPA transformations are performed
> (such as on AIX), there is no need to parse and regenerate the debugging
> info.
>
> If GCC needs to emit sections for each function early to define
> the types for the functions, such as using ELF sections, AIX XCOFF has
> similar functionality in CSECTs, which GCC already generates. This is a
> requirement for multiple sections, not ELF nor DWARF.
>
> I don't think that the original assertion about locking into DWARF
> is correct and I hope that LTO would not be designed and implemented to
> intentionally break AIX.
I don't see why we should need to parse the debug info again (which would
lock us in to whatever we want to parse). Instead I was suggesting simply to
emit the debug information for types and declarations "from the frontends"
and be done with it. But Kenny suggested (I don't know if that came through)
that for optimizations doing for example re-ordering of structure members
we would read the dwarf back in, apply the same transformation, and dump
it out again. I see no point in doing this.
Richard.