This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: new __cxa_demangle


Yo people.

I've been working on bringing in a new demangler. My first try was
posted right at the beginning of the Christmas holiday:

http://gcc.gnu.org/ml/libstdc++/2002-12/msg00274.html

It has been improved since. Some of the major advantages are:

1) it is maintained

2) it uses std::string

3) it allows for more flexible memory allocation/de-allocation via an
allocator template parameter.

4) it fixes the bugs in the current demangler

However there are a couple of things that I would like to mention, and
hopefully get some feedback.


One.

Because the new implementation of __cxa_demangle uses std::string
instead of dyn_string, there are dependencies on libstdc++ that are
difficult to untangle. I've tried, and the recent
_GLIBCPP_EXTERN_TEMPLATE patch was a result of this struggle, but have
been ultimately unsuccessful. Or, successful but the hacks are so gross
that I won't even post them. Instead, I propose to move the
__cxa_demangle sources into src, and remove the current bits in
libsupc++. This will result in __cxa_demangle being undefined in
libsupc++.a, and defined only in libstdc++.[a, so] (but versioned with
the runtime CXXABI name.)

Does anybody care about this? I'm not expecting this to be an issue.


Two.

The testsuite for __cxa_demangle will be added to
libstdc++-v3/testsuite/[demangle, abi]. I'm planning on adding them in
the new style (ie, consecutive numbers enclosed in directory, one case
a testsuite.) This will add a bunch of tests (say 10-50), which will
slow down 'make check' even more. Nobody is more bummed about the
slowdown than me, I assure you.

Also, as part of this, I intend to add parts of abi_check.cc to
libv3test.a, and to then link abi_check against this library. At some
point, the various utility routines that have been developed for the
library testing (testsuite_allocator, testsuite_hooks, abi_check) might
want to move into an enclosing directory. I don't intend to do this last
point at the moment, but might if I feel ambitious, or drink a lot of
coffee too late at night.

I think this plan is sound, and am proceeding in my work based on these
assumptions. Speak now....

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]