This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


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

Re: IA32: printing FP register variables


On Mon, Jul 26, 1999 at 01:42:41PM -0500, Jim Blandy wrote:
> Okay.  So the current plan is:
> 
> 1) EGCS folks get regstack to actually propagate the variable/register
>    mapping to its output accurately.

Yes, this is a reasonable plan.  As to a time frame... I don't know.

What we need is a good infrastructure for handling LRS debug info in
a convenient form within the compiler.  Whether this gets emitted as
dwarf2 location ranges, or stabs live ranges, or as a set of virtual
lexical blocks.  What Cygnus has now for LRS just won't work when the
size live ranges are on the order of instructions.

If someone has brilliant ideas how to manage and manipulate this stuff
in a way that won't make things an absolute nightmare, I'd be glad to
hear it.

I'll throw out one idea -- live ranges must always begin with a store.
What if we put a REG_START_RANGE in places that a user variable moves
to a new location.  And a REG_END_RANGE note in places a user variable
truely dies and its register gets re-allocated to some temp.  The value
of the note would be some canonical token that lets us match up with
the DECL in question.

Just before, or in the process of, emitting debug info, we use the
CFG and the REG_*_RANGE notes to transform this somewhat fluid form
into something that the debugger can use.

A particularly major open issue is how the optimizers can easily know
when they need to create these notes, and which variables the notes 
are being created for.  I could easily see it being a not insignificant
task to find this, given that it's all scattered about.  But the fact
that it's scattered about is crucial to being resiliant against
ever-changing insn sequences.

The extra memory and time might even call for it only being enabled
at -g3 or something.  Something we'll have to examine.

Thoughts?



r~

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