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