This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/RFC] fix problems with unwinder on mips-irix
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 2 Sep 2004 16:09:28 -0700
- Subject: Re: [RFA/RFC] fix problems with unwinder on mips-irix
- References: <20040723011059.GI20596@gnat.com> <410994BD.5040506@gnu.org> <20040803044358.GA18163@gnat.com> <411039F3.1020102@gnu.org> <20040830181829.GC969@gnat.com> <41338063.7020500@gnu.org>
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