[lldb-dev] LLDB expressions confused by overloading

[Aidan Dodds via lldb-dev]

Hi Greg,

It turns out that the problem I was having was fixed when I patched a 
bug in DwarfSymbolFile:
http://reviews.llvm.org/D14538

But thanks for the additional info.

Aidan


On 12/11/2015 17:54, Greg Clayton wrote:
>> On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> I believe I have tracked down an interesting bug which related to LLDBs expression parser.
>>
>> In my target program I have a math library, a shared object which makes use of clangs __attribute__((overloadable)) extension for C99.  This causes the the function names in the math library to be mangled.
>> A problem arises however since some of the function names mirror those exported by libm.so, and the function names in libm are not mangled.
>>
>> My problem scenario:
>> If I call an expression during a debugging session, the symbol table of libm.so is consulted first and a match will be found.  Later on in the expression setup, any dwarf information will be consulted for functions with this name.  libm.so doesn't have any debugging info attached, however the math library of my target may.  In this case the expression will now call which ever function it could first find dwarf info for, regardless of the name mangling.
>>
>> The net result is that a function will be called in my targets math library that may not match the given function signature.  In my case this causes the expression to raise a SEGFAULT and fail.  I was seeing an expression to call a vector4 function, in fact call the vector 2 version behinds the scenes.
>>
>> One solution to this problem seems to be to have the expression evaluator try and first look for any functions that may have a mangled name for the given function signature, and if that fails fall back to simply checking for the unmangled version, as is currently done.
>>
>> Would this make sense?
>>
>> It seems less then ideal to have a clash of mangled and unmangled names, but I can imagine this situation may not be all that rare.
> The correct fix for this is to have the DWARFASTParserClang, when it parses the function prototype, recognize that a C function (check the language of the compile unit) has a mangled name and enable the corresponding bit in the clang::FunctionType so that the expression parser knows to look for the mangled name when someone uses it. Then no changes to the expression parser should be required.
>
> Greg Clayton
>