From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 26839 invoked from network); 11 Jan 2003 18:34:22 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 11 Jan 2003 18:34:22 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18XSLC-0007Bo-00; Sat, 11 Jan 2003 14:34:50 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18XQSs-0000g6-00; Sat, 11 Jan 2003 13:34:38 -0500 Date: Sat, 11 Jan 2003 18:34:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [unwind-20030108-branch] Add sentinel-frame + misc Message-ID: <20030111183437.GB1930@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3E1E2D1B.5020100@redhat.com> <3E1E6C23.8050407@redhat.com> <20030110213400.GA8623@nevyn.them.org> <3E205F17.3060906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E205F17.3060906@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00456.txt.bz2 On Sat, Jan 11, 2003 at 01:14:47PM -0500, Andrew Cagney wrote: > >@@ -555,8 +522,14 @@ > >> If the value isn't here AND a value is needed, try the next inner > >> most frame. */ > >> > >>+struct frame_unwind_cache > >>+{ > >>+ void *regs[1]; > >>+}; > >>+ > > > > > >I know it makes some type-checking simpler, but naming all your private > >types > >the same thing is a real nuisance when using this lame "GDB" thing on > >the code afterwards. Must we? > > Looks like more bugs in gdb :-( It's hardly a bug; more of a deep interface shortcoming. Consider: File A declares a type 'struct foo'. File B declares a type 'struct foo'. Header C forward declares 'struct foo;' and 'struct foo *get_foo ()'. File D includes Header C and uses 'get_foo'. I'm sitting in File D, and I want to look in the debugger at this opaque unwind cache. There's no possible way to associate it with either struct foo. That's why I think the construct should be avoided; if one of them is A_foo and the other is B_foo, and we do a bit of casting, then at least I can dump the one I want. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer