This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] New method, frame_align(), use in MIPS
- From: Andrew Cagney <ac131313 at ges dot redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Wed, 11 Sep 2002 18:01:53 -0400
- Subject: Re: [patch/rfc] New method, frame_align(), use in MIPS
- References: <3D7E90FE.7040904@ges.redhat.com>
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