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


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.


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