This is the mail archive of the gdb-patches@sources.redhat.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]
Other format: [Raw text]

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


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



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