From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3838 invoked by alias); 3 Jan 2003 14:05:09 -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 3830 invoked from network); 3 Jan 2003 14:05:03 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (80.13.18.242) by 209.249.29.67 with SMTP; 3 Jan 2003 14:05:03 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id EA961D34AE; Fri, 3 Jan 2003 18:04:48 +0400 (RET) Date: Fri, 03 Jan 2003 14:05:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix a memory corruption in mdebugread.c Message-ID: <20030103140448.GH693@gnat.com> References: <20021231141520.GA1485@gnat.com> <20021231151216.GA27495@nevyn.them.org> <20030101133518.GA693@gnat.com> <20030101174132.GA15485@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yEPQxsgoJgBvi8ip" Content-Disposition: inline In-Reply-To: <20030101174132.GA15485@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-01/txt/msg00056.txt.bz2 --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 542 > 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. Class names appear not to be mangled, so indeed there should be no name "clash". I checked the following change in (I expanded the comment to explain that a method can not have the same name as the class name): 2003-01-03 J. Brobecker * mdebugread.c (parse_symbol): Count until the stEnd matching the structure name. -- Joel --yEPQxsgoJgBvi8ip Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mdebugread.c.diff" Content-length: 1891 Index: mdebugread.c =================================================================== RCS file: /cvs/src/src/gdb/mdebugread.c,v retrieving revision 1.32 diff -c -3 -p -r1.32 mdebugread.c *** mdebugread.c 17 Dec 2002 00:39:07 -0000 1.32 --- mdebugread.c 3 Jan 2003 13:59:00 -0000 *************** parse_symbol (SYMR *sh, union aux_ext *a *** 865,871 **** switch (tsym.st) { case stEnd: ! goto end_of_fields; case stMember: if (nfields == 0 && type_code == TYPE_CODE_UNDEF) --- 865,888 ---- switch (tsym.st) { case stEnd: ! /* C++ encodes class types as structures where there the ! methods are encoded as stProc. The scope of stProc ! symbols also ends with stEnd, thus creating a risk of ! taking the wrong stEnd symbol record as the end of ! the current struct, which would cause GDB to undercount ! the real number of fields in this struct. To make sure ! we really reached the right stEnd symbol record, we ! check the associated name, and match it against the ! struct name. Since method names are mangled while ! the class name is not, there is no risk of having a ! method whose name is identical to the class name ! (in particular constructor method names are different ! from the class name). There is therefore no risk that ! this check stops the count on the StEnd of a method. */ ! if (strcmp (debug_info->ss + cur_fdr->issBase + tsym.iss, ! name) == 0) ! goto end_of_fields; ! break; case stMember: if (nfields == 0 && type_code == TYPE_CODE_UNDEF) --yEPQxsgoJgBvi8ip--