From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22381 invoked by alias); 29 Jun 2006 11:01:41 -0000 Received: (qmail 22373 invoked by uid 22791); 29 Jun 2006 11:01:40 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 29 Jun 2006 11:01:39 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 78364544001; Thu, 29 Jun 2006 13:01:36 +0200 (CEST) Date: Thu, 29 Jun 2006 11:01:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [PATCH] m32c-tdep.c: Don't choke on virtual functions in push_dummy_call Message-ID: <20060629110136.GE18873@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20060628141839.GA29012@calimero.vinschen.de> <20060628213255.GA24718@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060628213255.GA24718@nevyn.them.org> User-Agent: Mutt/1.4.2i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00402.txt.bz2 On Jun 28 17:32, Daniel Jacobowitz wrote: > On Wed, Jun 28, 2006 at 04:18:39PM +0200, Corinna Vinschen wrote: > > Hi, > > > > the below patch fixes a couple of GDB internal errors when calling > > virtual C++ methods. Virtual methods are not represented as type > > TYPE_CODE_METHOD, but as TYPE_CODE_PTR pointing to TYPE_CODE_METHOD. > > The m32c_push_dummy_call function only checks the function type for > > TYPE_CODE_FUNC or TYPE_CODE_METHOD, which results in a failed assertion > > in case of virtual methods. The below patch skips TYPE_CODE_PTR types > > until it points to the actual TYPE_CODE_METHOD to evaluate further > > necessary data. > > > > Ok to apply? Mark Kettenis asked: > Hmm, I don't understand why this is a m32c-specific problem. > Shouldn't this be handled in generic code instead? [Mark, could you please not quote raw email addresses in the mail body? Thanks.] This isn't a m32c specific problem. m32c is right now the only architecture which needs access to the function type, so m32c is the only affected architecture. I don't know how this has to be handled in generaic code, actually. The function pointer which is given to the push_dummy_call function is a struct value, which points to the function value. The type stored here is a TYPE_CODE_PTR pointing to TYPE_CODE_METHOD. This makes sort of sense to me. > In addition to Mark's question, which I am also curious about - did > anything in the testsuite catch this, or if not, how can we reproduce > it? gdb.cp/virtfunc.exp. All tests calling virtual functions by hand. > - I am currently (i.e. right this moment) rewriting lots of this > stuff. You may wish to wait a little while - though be sure to poke me > about it if I don't have something to check in soon! It is all broken > anyway; GDB is not going to succeed at calling a virtual pointer, it's > going to go off into neverland. This I don't understand. Calling virtual methods works quite nicely, at least in my m32c case here. After dereferencing the method type, the m32c_push_dummy_call function passes all args correctly and the return value of the call is correct, too. As for the problem of having to dereference the virtual function type, Maybe it makes sense to do this in call_function_by_hand already. Or are you suggesting that the representation of virtual methods is incorrect in GDB? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat