On Sat, Jul 26, 2008 at 8:42 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On Sat, Jul 26, 2008 at 1:55 PM, Richard Guenther > <[EMAIL PROTECTED]> wrote: >> On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <[EMAIL PROTECTED]> 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. > > So how do you plan to keep the debug info up to date in the presence > of structure reordering/etc transforms?
Provide no debug information for these types/decls. Richard.
