[RFA] Fix a memory corruption in mdebugread.c
Joel Brobecker
brobecker@gnat.com
Wed Jan 1 13:35:00 GMT 2003
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.
> That's not a proper ChangeLog entry; it should be smeting like:
>
> 2002-12-31 J. Brobecker <brobecker@gnat.com>
>
> * mdebugread.c (parse_symbol): Count until the stEnd matching
> the structure name.
Sure!
--
Joel
More information about the Gdb-patches
mailing list