Hi Greg,
It turns out that the problem I was having was fixed when I patched a
bug in DwarfSymbolFile:
http://reviews.llvm.org/D14538
But thanks for the additional info.
Aidan
On 12/11/2015 17:54, Greg Clayton wrote:
On 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.
Would this make sense?
It seems less then ideal to have a clash of mangled and unmangled names, but I
can imagine this situation may not be all that rare.
The correct fix for this is to have the DWARFASTParserClang, when it parses the
function prototype, recognize that a C function (check the language of the
compile unit) has a mangled name and enable the corresponding bit in the
clang::FunctionType so that the expression parser knows to look for the mangled
name when someone uses it. Then no changes to the expression parser should be
required.
Greg Clayton
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
