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@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
