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: [patch/rfc] New method, frame_align(), use in MIPS


Thoughts?
Andrew
I think I've got the MIPS using generic dummy frames, it hurts ...

Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.69
diff -u -r1.69 valops.c
--- valops.c 21 Aug 2002 17:24:31 -0000 1.69
+++ valops.c 11 Sep 2002 00:02:01 -0000
@@ -1353,6 +1353,14 @@

old_sp = sp = read_sp ();

+ /* Grow the stack slightly so that the inital SP is correctly
+ aligned for the start of a new frame. Ensure that any stack
+ growth is in the correct direction */
+ if (gdbarch_frame_align_p (current_gdbarch))
+ sp = gdbarch_frame_align (current_gdbarch, old_sp);
+ gdb_assert ((INNER_THAN (1, 2) && sp <= old_sp)
+ || (INNER_THAN (2, 1) && sp >= old_sp));
+
if (INNER_THAN (1, 2))
{
/* Stack grows down */

I think the above will need to be changed in a way that ensures that the dummy frame is never empty -- at least some stack space is allocated.

For the MIPS, I hit a problem with GDB tieing its self in knots when doing recursive inferior function calls to frameless leaf functions.

This leads me to believe that there is a more fundamental problem when frameless functions get involved. Briefly:

Consider a sequence:

void frameless1(void) { ... };
void frameless2(void) { ... };

(gdb) break frameless1
(gdb) break frameless2
(gdb) call frameless1()

GDB doesn't need to push anything on the stack since frameless1() takes no parameters and can use a return address register. frameless1() doesn't adjust the SP either.

Breakpoint 1 in frameless1
(gdb) call frameless2()

Same story, GDB doesn't adjust the SP, frameless2() doesn't adjust the SP.

Breakpoint 2 in frameless 2
(gdb) bt
frameless2()
<dummy frame>
frameless1()
<dummy frame>
frameless1()
<dummy frame>
.
.
.


What happens?

GDB can differentiate between two frameless functions because, even when their SP is the same, this is because the enclosing functions will be different. On the other hand, it isn't possible to differentiate between the two dummy frames. This is because the PC and the SP/FP/TOS will be identical.

Consequently, GDB, when searching for a dummy frame will always find the first dummy frame and go into an infinite backtrace loop.

--

For the record, I encountered a case very similar to this. GDB was going into an infinite loop because, given a stack like:
sp=10 -- add(4,5)
sp=10, fp=5 -- dummy frame
sp=5 -- add(2,3)
sp=5, fp=0 -- dummy frame
generic_find_dummy_frame() would always find the first dummy frame. This is because the current_generic_find_dummy_frame checks for a match with any of SP, FP and TOS.

Andrew



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