Re: [lldb-dev] LLDB expressions confused by overloading
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 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
Re: [lldb-dev] LLDB expressions confused by overloading
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 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 >> 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
[lldb-dev] [Bug 25433] New: LLDB expressions confused by overloading
https://llvm.org/bugs/show_bug.cgi?id=25433 Bug ID: 25433 Summary: LLDB expressions confused by overloading Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ai...@codeplay.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Created attachment 15235 --> https://llvm.org/bugs/attachment.cgi?id=15235&action=edit Test case for lldbs testsuite to reproduce this problem. If a function is inconsistently overloaded and both mangled and unmangled versions are exported, it is possible that the expression parser will become confused and will call any of them, regardless of the function arguments. This could cause an expression, which calling a function like this to segfault the target. A test case is attached that will run as part of the lldb test suite which will reproduce this problem. Details of this problem were emailed to the lldb mailing list on the 5th nov 2015. The test case is setup as follows: I have one shared library, liba.so which exports a C function: int foo(float* v); I have another shared library, libb.so, which exports two functions with the overloaded attribute: int __attribute__((overloadable)) foo(float* f); int __attribute__((overloadable)) foo(int* f2); Additionaly, liba.so should be compiled without any debugging information, however libb.so can be compiled with debug info. I have a main executable which is linked against both of these shared libraries. If I try to call foo(int* f2) by passing in an int pointer as parameter, it will instead incorrectly execute the float version. Further more, if libb.so containst debug info, on one target I have seen lldb execute which ever version of the function it can find that has dwarf info associated with it. It seems inconsistent as to wether the test case exhibits this additional behaviour, however farther effort will be put into pinning this down. I think there is a case to be made for first trying to mangle the function the expression is calling and searching for that and as a fall back checking for the presence of the unmangled version. I belive this should correct this problem. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG] Regression: unprintable characters displayed
On Tue, Oct 20, 2015 at 04:09:16PM -0400, Ramkumar Ramachandra via lldb-dev wrote: > Hi, > > This does not happen with lldb-330.0.48, which ships with OS X, but > happens with HEAD: > > frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous > namespace)::CgJITMemManager::endFunctionBody(this=0x00010a715610, > F=0x00010a6da200, FunctionStart="^\n\x01", > FunctionEnd="??... Can you provide a test case, steps, and expected results please? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
