On Tue, Dec 23, 2008 at 8:03 PM, Cary Coutant 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?
> 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.
> 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.
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.
> The debug information for a given tree node will be stored in one of
> two separate global hash tables (one for decls, one for types),
> indexed by the UID, as a list of properties. Each separate fact that
> we need to record will be stored as a property, represented as a (key,
> value) pair. The property keys are simple small integers that identify
> the kind of property being recorded (e.g., Context, Base Classes,
> Member Methods, ...). The property values may be references to another
> tree, a list of trees, or simple integer or string values.
To support all of DWARF, you would need to have property keys for
everything that is in DWARF, so your property keys could be (should
be?) the DWARF tags and attributes.
Gr.
Steven
