Re: [RFA] use frame IDs to detect function calls while stepping

[Andrew Cagney <cagney@gnu.org>]

>>After two iterations (one for the call insn, and one for the delay
>>> slot), GDB lands at the begining of function "exit" at 0x00020950,
>>> which is:
>>> 
>>>         0x00020950 <exit+0>:    sethi  %hi(0xf000), %g1
>>>         0x00020954 <exit+4>:    b,a   0x20914 <_PROCEDURE_LINKAGE_TABLE_>
>>>         0x00020958 <exit+8>:    nop 
>>> 
>>> So at this point, the registers window has not been rotated.
>>> I don't know if this is the cause for this problem, but at this
>>> point GDB is unable to unwind the call stack:
>>> 
>>>         (gdb) bt
>>>         #0  0x00020950 in _PROCEDURE_LINKAGE_TABLE_ ()
>>> 
>>> (And gets the wrong procedure name as well, but that's a separate
>>> issue - although "x /i" does report what I believe is the correct
>>> name, strange!).
>>> 
>>> I am looking into the sparc unwinder code right now, to try to
>>> understand a bit better the source of the problem.
> 
> 
> I think I found the source of the glitch. I may have the solution
> to fix it, but my little finger is telling that it might be a bit
> too extreme... Maybe MarkK has some comments about this?

How about this as a compromize:

- in 6.1
your original patch (but with a comment saying that the
+      if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name))
is a hack and shouldn't be included in the mainline)

- in mainline:
Assuming Mark's ok with the sparc changes, your patch without that part?

This way 6.1 is robust regardless of which SPARC architecture code is in 
place.

Andrew