From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15435 invoked by alias); 5 Jan 2004 20:51:12 -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 15426 invoked from network); 5 Jan 2004 20:51:11 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sources.redhat.com with SMTP; 5 Jan 2004 20:51:11 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AdbgQ-00036u-00; Mon, 05 Jan 2004 15:50:42 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 0B1B04B35A; Mon, 5 Jan 2004 15:50:59 -0500 (EST) To: drow@mvista.com Subject: Re: [rfc/cp] method stub assertions Cc: gdb-patches@sources.redhat.com Message-Id: <20040105205059.0B1B04B35A@berman.michael-chastain.com> Date: Mon, 05 Jan 2004 20:51:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-01/txt/msg00106.txt.bz2 drow> No, that's not correct. hpread.c sets it the same way that drow> dwarf2read.c does, by calling smash_to_method_type and drow> smash_to_member_type. Ah, okay. > 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. Okay. I think evaluate_subexp_standard understands this -- that it has to go from method to domain type, and from domain type to some other base-class type that actually defines the vtable. > 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. That will be the next problem. I just wanted to be sure that I was actually fixing this problem. > 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. Rats. Okay. I'll withdraw my patch, and work on that instead. Michael C 2004-01-04 Michael Chastain * valops.c (find_overload_match): Assert that methods are not stubs. Do not assert that methods have domain types. * eval.c (evaluate_subexp_standard): Assert basetype and domain_type as needed.