From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11477 invoked by alias); 28 Jun 2006 21:23:15 -0000 Received: (qmail 11469 invoked by uid 22791); 28 Jun 2006 21:23:14 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Jun 2006 21:23:12 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k5SLN7JO016808 for ; Wed, 28 Jun 2006 23:23:08 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k5SLN5R1011206 for ; Wed, 28 Jun 2006 23:23:05 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k5SLN4uw029536; Wed, 28 Jun 2006 23:23:04 +0200 (CEST) Date: Wed, 28 Jun 2006 21:23:00 -0000 Message-Id: <200606282123.k5SLN4uw029536@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: gdb-patches@sourceware.org In-reply-to: <20060628141839.GA29012@calimero.vinschen.de> (message from Corinna Vinschen on Wed, 28 Jun 2006 16:18:39 +0200) Subject: Re: [PATCH] m32c-tdep.c: Don't choke on virtual functions in push_dummy_call References: <20060628141839.GA29012@calimero.vinschen.de> 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/msg00391.txt.bz2 > Date: Wed, 28 Jun 2006 16:18:39 +0200 > From: Corinna Vinschen > > 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? Hmm, I don't understand why this is a m32c-specific problem. Shouldn't this be handled in generic code instead? Mark