From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15226 invoked by alias); 2 Sep 2004 23:09:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15215 invoked from network); 2 Sep 2004 23:09:29 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 2 Sep 2004 23:09:29 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 78F0847D92; Thu, 2 Sep 2004 16:09:28 -0700 (PDT) Date: Thu, 02 Sep 2004 23:09:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] fix problems with unwinder on mips-irix Message-ID: <20040902230928.GF1216@gnat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41338063.7020500@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00051.txt.bz2 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