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


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.

Thanks, David


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