From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22968 invoked by alias); 5 Jan 2004 19:23:58 -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 22917 invoked from network); 5 Jan 2004 19:23:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Jan 2004 19:23:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AdaKS-0001kK-9G; Mon, 05 Jan 2004 14:23:56 -0500 Date: Mon, 05 Jan 2004 19:23:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc/cp] method stub assertions Message-ID: <20040105192356.GA29254@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040105115033.8376A4B35A@berman.michael-chastain.com> <20040105005048.A159C4B35A@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040105115033.8376A4B35A@berman.michael-chastain.com> <20040105005048.A159C4B35A@berman.michael-chastain.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00099.txt.bz2 On Sun, Jan 04, 2004 at 07:50:48PM -0500, Michael Chastain wrote: > I'm working on support for hp-ux aCC. > > When I call a C++ method, I get this assertion failure: > > call class_param.Aptr_a (&g_A) > /house/chastain/gdb/s1/gdb/valops.c:1942: internal-error: Assertion `TYPE_DOMAIN_TYPE (fns_ptr[0].type) != NULL' failed. > > This assertion is in find_overload_method: > > /* If we are dealing with stub method types, they should have > been resolved by find_method_list via value_find_oload_method_list > above. */ > gdb_assert (TYPE_DOMAIN_TYPE (fns_ptr[0].type) != NULL); > > The "domain type" is a pointer from the method to the base class > that defines the virtual table for the class that contains this method. > > Here is some history about this assertion: > > http://sources.redhat.com/ml/gdb-patches/2002-05/msg00413.html > > Unfortunately, hpread.c does not set TYPE_DOMAIN_TYPE. As far as I can > tell, only dwarf2read.c and stabsread.c set this field. No, that's not correct. hpread.c sets it the same way that dwarf2read.c does, by calling smash_to_method_type and smash_to_member_type. These are only used in hpread for DNTT_TYPE_PTRMEMFUNC and DNTT_TYPE_PTRMEM. dwarf2read, however, calls smash_to_method_type when creating a method type. > Fortunately, it appears that TYPE_DOMAIN_TYPE is really only needed for > calls through member pointers or member function pointers. Such calls > are forbidden with hp-ux som anyways. > > This patch adjusts some asserts. I want to change find_overload_method > so that the code asserts that methods are not stubbed (which is what it > really needs), and then change evaluate_subexp_standard so that it > asserts TYPE_DOMAIN_TYPE when it really uses them. Right now we assume that methods have a TYPE_DOMAIN_TYPE. This patch pushes more knowledge of limited debug readers out into the rest of GDB. I'd rather go the other direction - set a domain type. If I'm reading dwarf2read correctly it simply uses the enclosing class, not walking back to find the class containing the vtable as you describe above. It's for _classes_ that it behaves as described above. See the comment: /* For types with virtual functions (TYPE_CODE_STRUCT), VPTR_BASETYPE is the base class which defined the virtual function table pointer. For types that are pointer to member types (TYPE_CODE_MEMBER), VPTR_BASETYPE is the type that this pointer is a member of. For method types (TYPE_CODE_METHOD), VPTR_BASETYPE is the aggregate type that contains the method. Unused otherwise. */ > After I do this, gdb gets further, but then crashes anyways in: > > evaluate_subexp_standard > find_overload_match > value_virtual_fn_field > gnuv2_virtual_fn_field # WRONG! > value_primitive_field > check_typedef > > So the next problem after this is that the the abi type is set to > gnu-v2. When I do "set cp-abi hpaCC", gdb calls the function, > although I see further problems after that. You will need to find some way to autodetect this. Does aCC still produce SOM output, even for hppa64? If so you can use hp_som_object_present, but that's a gross hack. It would be better to find another way. See where we autodetect gnu_v3. > Anyways, my questions are: > > Am I on the right track? > Can I commit this? No, please try to set TYPE_DOMAIN_TYPE in hpread instead. I think around line 3950 is the only place you'll need to. Hmm... or perhaps calling smash_to_method_type at 3861. That may work. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer