[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