From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30317 invoked by alias); 1 Jan 2003 17:41:40 -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 30307 invoked from network); 1 Jan 2003 17:41:39 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 1 Jan 2003 17:41:39 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Tokc-0006xr-00 for ; Wed, 01 Jan 2003 13:42:02 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18Tms0-00042L-00 for ; Wed, 01 Jan 2003 12:41:32 -0500 Date: Wed, 01 Jan 2003 17:41:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix a memory corruption in mdebugread.c Message-ID: <20030101174132.GA15485@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20021231141520.GA1485@gnat.com> <20021231151216.GA27495@nevyn.them.org> <20030101133518.GA693@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030101133518.GA693@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00001.txt.bz2 On Wed, Jan 01, 2003 at 05:35:18PM +0400, Joel Brobecker wrote: > Hi Daniel, > > > So I assume the stProc is nested directly in the type, and we generate > > a complaint() in the default below? > > Right. > > > It's worth bearing in mind that we don't actually support C++ in > > mdebugread; debugging the C++ part won't work well at all. We won't > > recognize any member methods for instance. > > This is indeed good to know, although I kind of guessed this after > reading the code in mdebugread.c :). > > > My concern from your description is that a constructor may have the > > same name as the enclosing type. Are these mangled names? Qualified > > names? Base names, in which case the constructor is a problem? You > > should be able to figure this out from looking at a couple of the names > > found by the check below. > > The method names are mangled, same for the constructors and destructors. > For instance, one of the constructors for class TC_rule was > __ct__7TC_ruleXRC7TC_rule. The destructor was __dt__7TC_ruleXv > (actually, I assumed these stProc entries are constructors and > destructors, but this a guess based on the name). An example of stProc > entry for a method: FI_write__7TC_ruleXP4FILE. > > stMembers, on the other hand, are not mangled. But they don't come with > stEnd entries, so we should be safe. OK. Assuming that the name of the class's stEnd is not mangled like a constructor, my worry is unfounded. If you add a comment to that effect then this patch is OK. > > > That's not a proper ChangeLog entry; it should be smeting like: > > > > 2002-12-31 J. Brobecker > > > > * mdebugread.c (parse_symbol): Count until the stEnd matching > > the structure name. > > Sure! > > -- > Joel > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer