This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Fix a memory corruption in mdebugread.c
- From: Joel Brobecker <brobecker at gnat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Wed, 1 Jan 2003 17:35:18 +0400
- Subject: Re: [RFA] Fix a memory corruption in mdebugread.c
- References: <20021231141520.GA1485@gnat.com> <20021231151216.GA27495@nevyn.them.org>
> So I assume the stProc is nested directly in the type, and we generate
> a complaint() in the default below?
> 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.
> That's not a proper ChangeLog entry; it should be smeting like:
> 2002-12-31 J. Brobecker <firstname.lastname@example.org>
> * mdebugread.c (parse_symbol): Count until the stEnd matching
> the structure name.