Re: PATCH: Fix MI stack frame output for synthetic frames

[Andrew Cagney <ac131313@redhat.com>]

> Hi all,
> 
> We've recently found a little problem with the current gdb in MI
> mode with synthesized frames on the stack (a gdb call dummy or a
> stack handler).  Until last month, print_frame_info_base() would
> print information about these frames to stdout via printf_unfiltered;
> the reply to -stack-list-frames would have a FRAME tuple for level
> 0, skip level 1 (assuming that's the synthesized frame), then a
> FRAME tuple for level 2 and so on.

It should be possible to test the "<function called from gdb>" case. 
All the more main-stream architectures now use dummy-frames so any one 
of them can be used for the test.

Can you do that?

Andrew


> With Jeff's change a month ago -
> http://sources.redhat.com/ml/gdb-patches/2002-09/msg00777.html
> 
> a LEVEL field is being output, but no other parts of the FRAME tuple.
> (the FRAME tuple is a named tuple ("frame") with fields ADDR, FUNC,
> ARGS, and LINE if those are all available).  The output now looks like
> 
> ~"<signal handler called>\n"
> stack=[frame={level="0",addr=...,func=...},level="1",frame={level="2",addr=...},...]
> 
> I've attached a patch to emit a TUPLE with a func name of "<signal
> handler called>" or "<function called from gdb>" and to include
> the ADDR field.  I also took the opportunity to remove some code that'd
> been #if 0'ed since the original import on to sources.redhat.com in 1999.
> It's probably easier to read the new code than the patch -- I'll list the
> new code below and attach the patch.
> 
> 2002-11-08  Jason Molenda  (jmolenda@apple.com)
>       
>         * stack.c (print_frame_info_base): Emit full FRAME tuple for
>         gdb call dummy and signal handler synthetic stack frames; send
>         stack frame name through UI instead of stdout.
> 
> Jason