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 <ai...@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@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
