libc++abi

There is a new project at:

http://libcxxabi.llvm.org/

This is libc++abi, and is meant to be the low-level, Itanium ABI (http://www.codesourcery.com/public/cxx-abi/) implementation for libc++. There isn't much in there right now (additions welcome!). So far all that is in there is a demangler (__cxa_demangle).

The demangler has been split into three lower-level API's:

__demangle_tree
__demangle(const char* mangled_name, char* buf, size_t bs)

__demangle_tree
__demangle(const char* mangled_name);

char*
__demangle(__demangle_tree dmg_tree, char* buf, size_t* n, int* status);

The first two functions take a mangled name as input and output a __demangle_tree. This is the "parsing part" of demangling. The reason for two functions here is so that you can optionally pass in a buffer, which if large enough, will be used instead of allocating memory for the __demangle_tree.

The third function takes the __demangle_tree, and outputs an unmangled name.

Using this low-level API, __cxa_demangle becomes a trivial wrapper above this API:

char*
__cxa_demangle(const char* mangled_name, char* buf, size_t* n, int* status)
{
    if (mangled_name == NULL || (buf != NULL && n == NULL))
    {
        if (status)
            *status = __libcxxabi::invalid_args;
        return NULL;
    }
    const size_t bs = 64 * 1024;
    char static_buf[bs];

    buf = __libcxxabi::__demangle(__libcxxabi::__demangle(mangled_name,
                                                          static_buf, bs),
                                  buf, n, status);
    return buf;
}

It is expected that some tools (compilers, debuggers) will want to make use of an API on __demangle_tree that has yet to be developed. E.g. how many function arguments and what are they? How many template arguments and what are they? etc.

Howard

So what's the chance of code from the package linked at [1] going in?

Sebastian

[1] http://home.roadrunner.com/~hinnant/

A large portion of [1] is GPL2 licensed code and thus not appropriate for libc++abi. However some of the easier parts of this library have been used in [1] and can be put into libc++abi. These "easy parts" include operator new/delete and the get/set new_handler. The exception-handling stuff is the hard part and that's GPL2.

Howard

Hi Howard,

I have to let the cat out of the bag a bit early, but there is going to be BSD licensed code doing this exact thing released very soon. (Sorry everyone I’m the bottleneck)

You’re of course free to work on what you want, but a few notes

  1. It’s used in production already
  2. It’s been tested with LLVM, PathScale and possibly other compilers
  3. It’s portable across FreeBSD, Linux, Solaris, OSX… etc
  4. Has good inline documentation
  5. Smallest/fastest C++ runtime in the industry based on my tests

./C

ps. Someone kick me if it’s not in the wild by later today

Looks like it has been released now!

http://pathscale.com/node/265
https://github.com/pathscale/libcxxrt

Jay.

Hi Howard,

I have to let the cat out of the bag a bit early, but there is going to be BSD licensed code doing this exact thing released very soon. (Sorry everyone I’m the bottleneck)

You’re of course free to work on what you want, but a few notes

  1. It’s used in production already
  2. It’s been tested with LLVM, PathScale and possibly other compilers
  3. It’s portable across FreeBSD, Linux, Solaris, OSX… etc
  4. Has good inline documentation
  5. Smallest/fastest C++ runtime in the industry based on my tests

./C

ps. Someone kick me if it’s not in the wild by later today

Is that means https://github.com/pathscale/libcxxrt will be merged into libc++abi?

It means that libcxxrt implements the Itanium C++ ABI now and you can
test. I've asked someone who has done this to post instructions and
hopefully we get those up soon.

Hi Yonggang,

After discussion, we decided not to do this. The bulk of libcxxrt is an older demangler (that doesn’t support C++'0x) that I think they’re planning to drop. The rest of the code is relatively minor stuff like implementation of std::bad_alloc and a few other glue things that should be straight-forward to implement in libc++abi. Since adding an external dependency complicates the licensing and distribution model, we’re prefer to keep the LLVM libc++abi independent of libcxxrt.

-Chris

We're going to improve the current demangler code to handle C++0x as
the one in libc++abi is currently bloated and complicated beyond
belief. (Larger than the whole runtime).

For the record "we" didn't decide to do this at all - it was *you* who
decided this. *We* (PathScale) are/were very willing to do everything
we could to collaborate and make this work. Your proposal to fork
libcxxrt based on unspecified future possibilities seemed
unreasonable.

I really see no reason you can't setup a git mirror or something.
People will have to build 2 projects and clone the source from github
vs llvm.org shouldn't be a deal breaker. Apple is of course free to
do whatever they want, but why duplicate yet another wheel? (We have
no plans to be a problematic upstream - we're not the FSF)

After discussion, we decided not to do this. The bulk of libcxxrt is an
older demangler (that doesn't support C++'0x) that I think they're planning
to drop. The rest of the code is relatively minor stuff like implementation
of std::bad_alloc and a few other glue things that should be
straight-forward to implement in libc++abi. Since adding an external
dependency complicates the licensing and distribution model, we're prefer to
keep the LLVM libc++abi independent of libcxxrt.

<snip>

For the record "we" didn't decide to do this at all - it was *you* who
decided this.

Sorry to be unclear, by "we" I meant the llvm project, of which I'm a representative.

I really see no reason you can't setup a git mirror or something.
People will have to build 2 projects and clone the source from github
vs llvm.org shouldn't be a deal breaker. Apple is of course free to
do whatever they want, but why duplicate yet another wheel? (We have
no plans to be a problematic upstream - we're not the FSF)

This is not an apple thing, apple already has a solution. I'm speaking on behalf of the project. Setting up git mirroring and complicating the licensing is not worth it for a couple hundred lines of code.

-Chris

This is incorrect. The bulk of the code is the exception handling / RTTI logic - this is nontrivial to implement correctly and is invoked by a significant amount of C++ code, often on important code paths, while the demangler is largely used for debugging and error reporting (for example, in the uncaught exception handler).

The demangler is from libelftc - we tried importing the demangler from libc++abi, but it turned out to increase the total object code size of libcxxrt by a factor of four, which is unacceptable for a core system library like this.

We may replace the libelftc demangler with something else at some point, but the current code fits the requirements of libcxxrt:

- Lightweight
- Good performance
- Permissively licensed

If libelftc gains support for the C++0x extensions, then we will just import their code. Otherwise, we will probably extend it ourselves and push the improvements upstream. While I like Howard's interface to the demanger for use by clients such as debuggers that require rich introspection of C++ encodings, it is massively overengineered for use in a C++ runtime library, which just requires to dump the encodings into a string, with minimal space requirements (as one common use for this code is dumping a type when you have run out of memory).

David
(author of most of libcxxrt)

-- Send from my Jacquard Loom