> From: Jason Thorpe <thorpej@nas.nasa.gov>
>
> On Thu, 13 Jan 2000 17:23:25 -0800 (PST) 
>  Ross Harvey <ross@ghs.com> wrote:
>
>  > >  > Is there hope of this being fixed eventually, or are the trap frames
>  > >  > processor-variant-specific (which would make this more difficult, I
>  > >  > assume)?
>  > >
>  > > It's possible to fix; look at alpha/alpha/db_trace.c.  Someone just has
>  > > to do it.
>  > 
>  > I dimly recall a recent mention of a ddb(4) traceback-over-trap problem.
>
> Nonono.... I mean, look at db_trace.c -- it's possible to fix gdb :-)

Right, I got that, but thought I would throw in my "huh?!" to the other
report of ddb(4) not traversing palcode vector frames, which AFAIK it
does perfectly.

>  > Now, gdb is another story. It has no concept of trap frames,  and locore.s
>  > has some hand stabs that, at one point, worked a bit, sometimes. It really
>  > needs to be fixed in gdb. Unfortunately, the technique used by ddb(4)
>  > doesn't translate well to gdb, but if anyone wants to work on it I will
>  > spell out what's required.
>
> Well... as long as GDB knows the value of the Xent* symbols... wouldn't that
> work?  That is, in fact, how the DDB traceback used to work until you changed
> it to just use a pointer to the entry points themselves.

Sure, I suppose it *could* work like ddb(4), i.e.  hardwire knowledge of
the trap frame entry points and deduce from that the stack layout. The
problem with that is: the stack tracer in gdb is shared code, and such a
mechanism that would then be used only on NetBSD. It would work, and might
be taken back, but I thought that the designed (but unimplemented) mechanism
was the IM_EXC bit in the register mask:

	.mask   registermask | IM_EXC

Gdb, it would appear, should be looking for IM_EXC and if present understand
the palcode vector format with the specified saved registers. Just recognizing
IM_EXC should be at least as easy as building in a list of magic symbols:
the hard part comes next anyway as you try to hack on the large and convoluted
module that decodes the "almost impenetrable" (as the gdb comment notes)
ALPHA stack frames. Actually, the MIPS module has the same comment, making
me think it's inaccurate for alpha, and perhaps explains the complexity of
that stack tracer .. if it wasn't written from the ground up for alpha.

	ross