Re: [RFA/RFC] fix problems with unwinder on mips-irix

[Joel Brobecker <brobecker@gnat.com>]

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