[RFA/RFC] fix problems with unwinder on mips-irix
Joel Brobecker
brobecker@gnat.com
Thu Sep 2 23:09:00 GMT 2004
Andrew,
FYI: This is something I have started investigating but can't finish
just yet because I have to move off to something else. You said:
> This kernel_trap stuff isn't applicable here.
>
> > kernel_trap = PROC_REG_MASK (proc_desc) & 1;
> > gen_mask = kernel_trap ? 0xFFFFFFFF : PROC_REG_MASK (proc_desc);
> > float_mask = kernel_trap ? 0xFFFFFFFF : PROC_FREG_MASK (proc_desc);
But in fact for a reason I don't completely understand just yet, we
do have kernel_trap set occasionally (I measured ~300+ times in our
testsuite). For instance, in all-bin.exp, debugging all-types:
(gdb) break main
(gdb) run
Starting program: /[...]/all-types
Breakpoint 1, main () at all-types.c:35
35 dummy();
(gdb) next
!! -> *** DEBUG: kernel_trap in mips_insn32_frame_cache ***
36 return 0;
I don't have all the details just yet, but my semi-educated guess
is that the sequence of events that lead to this is the following:
. User enters next command
. GDB does a next, and waits for events
. We land inside dummy (unverified)
. Put a temporary breakpoint at return address, continue (unverified)
. Land at return address
. and somehow find ourselves unwinding past main inside __start.
(and no, I don't think this qualifies as a kernel trap - but if
I remove this code, I get lots of new failures)
I'll look at this and all your other suggestion a bit later, when
I have some time again.
--
Joel
More information about the Gdb-patches
mailing list