[lldb-dev] [Bug 25433] New: LLDB expressions confused by overloading

[via lldb-dev]

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 at lists.llvm.org
          Reporter: aidan at codeplay.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151106/8d4c188f/attachment.html>