From mboxrd@z Thu Jan 1 00:00:00 1970 From: Troy Rollo To: Daniel Berlin Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Borland TDS reading + BFD Interface Change Date: Thu, 24 Aug 2000 03:36:00 -0000 Message-id: <4.3.1.2.20000822192249.00dbe870@mail> References: <4.3.1.2.20000820133938.00aa7100@mail> X-SW-Source: 2000-08/msg00296.html 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/