Borland TDS reading + BFD Interface Change
Troy Rollo
troy@rollo.com
Thu Aug 24 03:36:00 GMT 2000
At 21:14 19/08/00 -0700, Daniel Berlin wrote:
>libiberty's demangler module provides a generic interface to demangling
>any c++ symbol.
>
>You should be able to add any type of demangler into it, no matter how
>dissimilar.
I actually started off by trying to slot it into cplus-dem.c, but based on
a quick look at the code I have, which only seems to handle GNU, LUCID,
ARM, HP and EDG, which all seem to be using basically the same scheme, the
TDS stuff couldn't be integrated in except at the very top level. I didn't
think it would be appropriate to hook Borland demangling into
cplus_demangle or internal_cplus_demangle when it's really only useful for
one platform.
The approach I took instead was to make sure that every symbol that could
be demangled was demangled when the symbols were read in.
If I hook into cplus_demangle or internal_cplus_demangle, there are other
problems to overcome:
1. Borland changed the mangling scheme between TDS version 9 (BC++4.x) and
TDS version 10 (BC++5.x). Unfortunately, there isn't even a reliable way to
tell which mangling scheme is in use just from the symbol, so it would
require either two enum values for the different schemes, or a willingness
to forgo TDS version 9 (which is probably reasonable since it's primarily
the free beer compiler that of most interest).
2. Because Borland partially mangles many of its symbols, we'd have to
substitute fully mangled symbols at read in time so the demangler could
correctly demangle them. This is feasible, although it's something I was
hoping to avoid - although there's one bonus to be had from that in that
the interaction with c_type_print could be removed.
>It makes it amazingly difficult to do useful C++ debugging if your
>demangler must be called seperately. We need to simply be able to use
>cplus_demangle, and get the right stuff back, no matter what the mangling
>scheme used is.
That's why I demangled everything at the time of reading symbols - I
thought I might avoid the need to call cplus_demangle but it sounds like
that's not enough.
Assuming you want to go the route of ditching TDS version 9 and fully
mangling the symbols at symbol read time so they can be reliably demangled,
how should the hook into cplus_demangle or internal_cplus_demangle be made?
I'm assuming this needs to be done in such a way that platforms that don't
need it don't have to have it.
______________________________________________________________________________
troy@rollo.com Troy Rollo, Sydney, Australia
Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/
More information about the Gdb-patches
mailing list