This is the mail archive of the 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: Dummy frames broken on PowerPC

>> (gdb) finish
>> Run till exit from #0 0x100004c8 in marker2 (a=99) at >/mnt/loc-computed/src-noindent/src/gdb/testsuite/gdb.base/break.c:49
>> /mnt/loc-computed/src-noindent/src/gdb/dummy-frame.c:295: >internal-error: dummy_frame_pop: Assertion `get_frame_type (fi) == >DUMMY_FRAME' failed.
>> A problem internal to GDB has been detected. Further debugging may >prove unreliable.
>> Quit this debugging session? (y or n)
>What does the backtrace look like?

I get

(gdb) bt
#0 0x1000037c in _start ()

>I suspect frame_type_from_pc() may have some of all the logic needed to
>spot a dummy frame. Contrast it with dummy_frame_p(). However, I've no
>basis for this - the ppc doesn't use the new frame code and the only
>other time it could affect things is with create_new_frame() - that,
>ignoring MIPS and SPARC, has only one call.
>Anyway, try changing the logic to test (dummy_frame_p() != NULL) when

I don't know if this is what you meant, but this patch fixes it (Not that I'm actually going to submit it. It looks ugly).

Index: dummy-frame.c
RCS file: /cvs/src/src/gdb/dummy-frame.c,v
retrieving revision 1.10
diff -u -p -r1.10 dummy-frame.c
--- dummy-frame.c 19 Jan 2003 17:39:16 -0000 1.10
+++ dummy-frame.c 18 Feb 2003 03:11:21 -0000
@@ -292,7 +292,11 @@ dummy_frame_pop (struct frame_info *fi,
struct dummy_frame *dummy = cached_find_dummy_frame (fi, cache);

/* If it isn't, what are we even doing here? */
+ gdb_assert (dummy_frame_p(fi->pc) != NULL);
gdb_assert (get_frame_type (fi) == DUMMY_FRAME);

if (dummy == NULL)
error ("Can't pop dummy frame!");

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