[llvm] r197988 - llvm-symbolizer: add --obj flag to specify a single object file that should be symbolized.

Ed Maste emaste at freebsd.org
Wed Jan 15 05:06:10 PST 2014


On 15 January 2014 04:51, Roman Divacky <rdivacky at freebsd.org> wrote:
> Uhm... we should fix the __cxa_demangle bug and just XFAIL the test on FreeBSD?

If we expect end users to use llvm-symbolizer though, it would seem
broken for users on existing FreeBSD releases.  While looking into
this though I now think there's a larger issue.  The Itanium C++ ABI
states the string passed to __cxa_demnagle "may be either an external
name, i.e. with a "_Z" prefix, or an internal NTBS mangling, e.g. of a
type for type_info."  "main" is neither, and FreeBSD's __cxa_demangle
should be made more strict to reject it.

However that still leaves types -- I think llvm-symbolizer would
return "float" for a function "f".  The test input used for the --obj
flag helpfully has a function named "f" already, so I used that for an
additional test - perhaps someone can try it on another platform.

The change and test are here: http://llvm-reviews.chandlerc.com/D2552



> On Tue, Jan 14, 2014 at 07:26:31PM -0500, Ed Maste wrote:
>> On 8 January 2014 13:39, Roman Divacky <rdivacky at freebsd.org> wrote:
>> > It looks like a genuine bug, it outputs:
>> >
>> > unsigned long
>> > /tmp/dbginfo/dwarfdump-test.cc:16:0
>> >
>> > ie. "unsigned long" instead of the expected "main", no idea why.
>>
>> As it happens this seems to be a bug in FreeBSD's __cxa_demangle,
>> which returns "unsigned long" for "main" as input.
>>
>> LLDB on FreeBSD previously experienced demangler issues with complex
>> mangled names, but handled unmangled names correctly.  It turns out
>> that LLDB first checks that names are actually mangled before calling
>> the demangler, and so avoids this issue:
>>
>> static inline bool
>> cstring_is_mangled (const char *s)
>> {
>>     if (s)
>>         return s[0] == '_' && s[1] == 'Z';
>>     return false;
>> }
>>
>> Is it reasonable to introduce a similar check in llvm-symbolizer?



More information about the llvm-commits mailing list