On Wed, Dec 24, 2008 at 11:07 AM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Tue, Dec 23, 2008 at 8:03 PM, Cary Coutant <ccout...@google.com> wrote: >> Another approach is to generate the debug information earlier -- in >> the front-end. This approach would significantly alter the structure >> of the compiler and would be a major undertaking. > > Would it be more work than what you are proposing?
Probably not. >> In addition, many >> back-end transformations affect the debug information, so the back-end >> would then need an infrastructure for decoding the debug information, >> modifying it, then re-encoding it. > > What transformations are you thinking of? Maybe it is acceptable for > some transformations (e.g. high level loop transforms, aggregate type > reorganization, etc.) to disrupt debug info beyond repair. He is probably speaking about things we don't support very well (or at all) at the moment either - like struct-reorg or SRA. >> Such an approach might be practical >> for a single debug format, but in order to support the several formats >> that gcc currently supports, it would also become a major undertaking. > > But for your approach you effectively end up inventing a completely > new debug info format. Indeed. IMHO a very bad idea. > Hve you considered to just use DWARF and translate the DWARF debug > info to a different format in LTRANS? For example, user wants stabs, > LGEN generates DWARF, LTRANS reads in the DWARF, and dbxout is > modified to translate the DWARF to stabs. +1 Streaming out DWARF for the frontend specific debug information (that is, debug info for types and decls) from the frontend is the way to go. You can refer to the debug information by simply using the DIE uids. Not that I didn't propose this often enough ... Richard.
