[lldb-dev] LLDB expressions confused by overloading

[Siva Chandra via lldb-dev]

Note that my patch is C++ specific. You might want to try by
commenting out the C++ check. Also, since in your case something
(though wrong) is actually found, you will have to change the ordering
of tries in ClangExpressionDeclMap::GetFunctionAddress.

On Fri, Nov 6, 2015 at 3:12 AM, Aidan Dodds <aidan at codeplay.com> wrote:
> Thanks Siva,
> This indeed looks somewhat related to the problems we are seeing here.
> I'm just having a read of your patch now and going to try it out here.
>
>
> On 05/11/2015 18:24, Siva Chandra wrote:
>>
>> On Thu, 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.
>>
>> Is this similar to the problem tackled by this patch:
>> http://reviews.llvm.org/D12809
>
>