[cfe-dev] Targeting ARM with Clang

Howard Hinnant hhinnant at apple.com
Wed Mar 30 06:07:40 PDT 2011


On Mar 29, 2011, at 11:25 PM, Chris Lattner wrote:

> On Mar 29, 2011, at 2:41 PM, Marshall Clow wrote:
>> * C++ ABI library							- ??? [ On x86, I can use libcppabi - but not on ARM ]
> 
> One specific, but important, piece of this is cxa_demangle.  Howard, do you want to talk about your recent work on this?

Sure! :-)

I've been working on a clean-sheet replacement for:

char* __cxa_demangle(const char* mangled_name,
				   char* buf,
				   size_t* n,
				   int* status);

http://www.codesourcery.com/public/cxx-abi/abi.html

It is still under development, and isn't quite yet ready for prime time, but it is coming along nicely.  I just recently passed the milestone of demangling every symbol in the clang compiler as compiled on OS X.  This implementation will eventually demangle all of the new C++0x symbols, but that part of the work is just barely started.

This implementation also sports a new lower-level interface meant for tools such as compilers and debuggers:

----------

typedef void* (*__alloc)(size_t);
typedef void* (*__realloc)(void*, size_t);
typedef void  (*__dealloc)(void*);

// Phase 1

__demangle_tree
__demangle(const char* mangled_name);

__demangle_tree
__demangle(const char* mangled_name, __alloc allocate, __realloc,
           __dealloc deallocate);

// Phase 2

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

char*
__demangle(__demangle_tree dmg_tree, char* buf, size_t* n,
           int* status, __alloc, __realloc reallocate, __dealloc);

----------

The idea is that demangling is a two-phased process:

   Phase 1:  From the mangled name, produce a syntax tree which represents the symbol.

   Phase 2:  From the syntax tree, produce a demangled name.

This lower-level API allows clients to call phases 1 and 2 separately, and exposes that internal syntax tree.  It is far from settled exactly what the API will be for the tree, but it seems clear that clients ought to be able to query it for things like template parameters, function parameters, etc.

Additionally clients will be able to pass in optional function pointer arguments to replace malloc, realloc and free.  All memory allocations (for the demangled name buffer, and for the tree) will use these optional function pointer arguments.  I will also document a heuristic for the maximum amount of memory that will be allocated.  This will allow clients to supply very fast allocators, for example a pointer to a stack-based buffer.  Here is an example of such a fast allocator that I've been successfully experimenting with:

void* quick_malloc(std::size_t n)
{
    const std::size_t max = 2*1024;
    static char buf[max];
    if (n < max)
        return buf;
    return 0;
}

void* quick_realloc(void*, std::size_t)
{
    return 0;
}

void quick_dealloc(void*)
{
}

To get a feel for the basic use of this low-level API, here is what the implementation of __cxa_demangle reduces to:

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 = invalid_args;
        return NULL;
    }
    buf = __libcxxabi::__demangle(__libcxxabi::__demangle(mangled_name),
                                  buf, n, status);
    return buf;
}

Here you see that the demangle tree is not queried, but simply passed directly from phase 1 to phase 2.

No estimate on when this will be done.  It has already taken a lot longer than I had anticipated, largely due to my lack of previous experience with the mangling rules:

http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

-Howard




More information about the cfe-dev mailing list