Re: Borland TDS reading + BFD Interface Change

[Troy Rollo <troy@rollo.com>]

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/