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

[Joel Brobecker <brobecker@gnat.com>]

Ok, I'm dark red with shame.

> Yes, there is a regression (regression #2 in my previous message) if
> we leave that test out. It's been a while since I posted that patch,
> so I don't remember the details anymore :-/. I'll dig again later today.

It looks like my initial analysis of the cause of regression #2 was
wrong. I will simply say that I was mislead by the fact that GDB
reported that we stopped in "_PROCEDURE_LINKAGE_TABLE_" while we
were actually inside function "exit", and let it go at that.

Here is a description of the regression which appears if we don't
include the following test:

+      if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name))
+        {
+          /* We landed in a shared library call trampoline, so it
+             is a subroutine call.  */
+          handle_step_into_function (ecs);
+          return;
+        }

The problem occurs with ending-run:

        % gdb ending-run
        (gdb) b ending-run.c:33
        Breakpoint 1 at 0x10828: file gdb.base/ending-run.c, line 33.
        (gdb) run
        Starting program: /[...]/gdb.base/ending-run 
        -1 2 7 14 23 34 47 62 79  Goodbye!
        
        Breakpoint 1, main () at gdb.base/ending-run.c:33
        33      }
        (gdb) n
        0x000105ec in _start ()
        (gdb) n
        Single stepping until exit from function _start, 
        which has no line number information.
        0x00020950 in _PROCEDURE_LINKAGE_TABLE_ ()

The expected behavior for the last "next" command is for GDB
to run until the inferior exits:

        (gdb) n
        Single stepping until exit from function _start, 
        which has no line number information.
        
        Program exited normally.

Unfortunately, here is what happens. At 0x000105ec, before we do
our second "next" command, we are about to execute the following
code:

        0x000105ec <_start+100>:        call  0x20950 <exit>
        0x000105f0 <_start+104>:        nop 

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.

-- 
Joel