From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14653 invoked by alias); 18 Feb 2003 01:59:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14642 invoked from network); 18 Feb 2003 01:59:34 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 01:59:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1I1xYK13799 for ; Mon, 17 Feb 2003 20:59:34 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1I1xXa29593; Mon, 17 Feb 2003 20:59:33 -0500 Received: from localhost.localdomain (vpn50-1.rdu.redhat.com [172.16.50.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1I1xWs14551; Mon, 17 Feb 2003 20:59:32 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1I1xRu01312; Mon, 17 Feb 2003 18:59:27 -0700 Date: Tue, 18 Feb 2003 01:59:00 -0000 From: Kevin Buettner Message-Id: <1030218015926.ZM1309@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: frame_register_unwind(): "frame != NULL" assertion failure" (Feb 17, 4:37pm) References: <1030213212349.ZM2427@localhost.localdomain> <20030213212904.GA14115@nevyn.them.org> <1030213213526.ZM2489@localhost.localdomain> <1030213214819.ZM2541@localhost.localdomain> <1030213232706.ZM8198@localhost.localdomain> <3E4D042F.3060102@redhat.com> <20030214151451.GC30416@nevyn.them.org> <3E5101BA.5000504@redhat.com> To: Andrew Cagney , Daniel Jacobowitz Subject: Re: frame_register_unwind(): "frame != NULL" assertion failure Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2003-02/txt/msg00291.txt.bz2 On Feb 17, 4:37pm, Andrew Cagney wrote: > Anyway, Kevin, >=20 > /* Use proc_desc calculated in frame_chain */ > proc_desc =3D > get_next_frame (fci) > ? cached_proc_desc > : find_proc_desc (get_frame_pc (fci), get_next_frame (fci), 1); >=20 > can you please change the above to be: >=20 > : find_proc_desc (get_frame_pc (fci), NULL, 1); >=20 > (with a comment) and modify read_next_frame_reg() to, when NULL, pull a=20 > value from the register cache. I have done this, but I am still seeing the assertion failure. The reason is slightly different, however. Here's a partial backtrace: outer-gdb> bt #0 internal_error (file=3D0x84ae60 "/home/devel/kevinb/sourceware-mips64/s= rc.baseline/gdb/frame.c", line=3D187, string=3D0x84aea0 "%s%sAssertion `%s'= failed.") at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/utils.c= :800 #1 0x005e4cf4 in frame_register_unwind (frame=3D0x0, regnum=3D31, optimize= dp=3D0x7fff6dc8, lvalp=3D0x7fff6ddc, addrp=3D0x7fff6dd0, realnump=3D0x7fff6= c80, bufferp=3D0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.base= line/gdb/frame.c:187 During symbol reading, struct/union type gets multiply defined: struct elf_= obj_tdata. #2 0x005479cc in mips_get_saved_register (raw_buffer=3D0x7fff6db8 "\020\00= 2\177=B0\177=FFm=C8\020\002\177=B0\177=FFm=D0", optimizedp=3D0x7fff6dc8, ad= drp=3D0x7fff6dd0, frame=3D0x100573c8, regnum=3D31, lvalp=3D0x7fff6ddc) at /= home/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:5509 #3 0x00513dc4 in gdbarch_get_saved_register (gdbarch=3D0x10061790, raw_buf= fer=3D0x7fff6db8 "\020\002\177=B0\177=FFm=C8\020\002\177=B0\177=FFm=D0", op= timized=3D0x7fff6dc8, addrp=3D0x7fff6dd0, frame=3D0x100573c8, regnum=3D31, = lval=3D0x7fff6ddc) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb= /gdbarch.c:3931 #4 0x005e500c in frame_register (frame=3D0x100573c8, regnum=3D0, optimized= p=3D0x7fff6dc8, lvalp=3D0x7fff6ddc, addrp=3D0x7fff6dd0, realnump=3D0x7fff6d= d8, bufferp=3D0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/src.basel= ine/gdb/frame.c:212 #5 0x005e6eb0 in frame_saved_regs_register_unwind (frame=3D0x100573c8, cac= he=3D0x100573ec, regnum=3D31, optimizedp=3D0x7fff6dc8, lvalp=3D0x7fff6ddc, = addrp=3D0x7fff6dd0, realnump=3D0x7fff6dd8, bufferp=3D0x7fff6db8) at /home/d= evel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:672 #6 0x005e4d60 in frame_register_unwind (frame=3D0x100573c8, regnum=3D31, o= ptimizedp=3D0x7fff6dc8, lvalp=3D0x7fff6ddc, addrp=3D0x7fff6dd0, realnump=3D= 0x7fff6dd8, bufferp=3D0x7fff6db8) at /home/devel/kevinb/sourceware-mips64/s= rc.baseline/gdb/frame.c:190 #7 0x0053687c in read_next_frame_reg (fi=3D0x100573c8, regno=3D31) at /hom= e/devel/kevinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:1599 #8 0x00536ff4 in mips_frame_saved_pc (frame=3D0x100573c8) at /home/devel/k= evinb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:1722 #9 0x00518c3c in gdbarch_frame_saved_pc (gdbarch=3D0x10061790, fi=3D0x1005= 73c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/gdbarch.c:47= 42 #10 0x0053a958 in mips_frame_chain (frame=3D0x100573c8) at /home/devel/kevi= nb/sourceware-mips64/src.baseline/gdb/mips-tdep.c:2434 #11 0x00518710 in gdbarch_frame_chain (gdbarch=3D0x10061790, frame=3D0x1005= 73c8) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/gdbarch.c:46= 90 #12 0x005e7fd0 in legacy_get_prev_frame (next_frame=3D0x100573c8) at /home/= devel/kevinb/sourceware-mips64/src.baseline/gdb/frame.c:1012 #13 0x005e87a0 in get_prev_frame (next_frame=3D0x100573c8) at /home/devel/k= evinb/sourceware-mips64/src.baseline/gdb/frame.c:1253 #14 0x004f61f8 in backtrace_command_1 (count_exp=3D0x0, show_locals=3D0, fr= om_tty=3D1) at /home/devel/kevinb/sourceware-mips64/src.baseline/gdb/stack.= c:975 If I were to follow your above suggestion, I would also have to add some explicit regcache fetching code to mips_get_saved_register() too, but I really can't believe that this is the best approach. To cleanly solve this problem, I believe that get_next_frame needs to be able to return the sentinel frame. But in order to do so, current usages of get_next_frame() need to be fixed to not check for NULL. The other approach, less clean, but certainly expeditious, is to use a hack similar to the one that I've already posted for frame_register_unwind(). Kevin