Thanks Jim, thats some very helpful information.
Sounds like we should take a closer look at our setup to see why the
existing precedence is having trouble resolving this for us.
Aidan
On 29/06/16 18:24, Jim Ingham wrote:
We have a not-yet-implemented scheme to allow some syntax like:
(lldb) expr $$foo.c$bar(5)
that would mean: look up the version of bar defined in foo.c and call that. What I wrote
above isn't right, since the "." is going to cause the parser headaches, so we'll
have to come up with some cleverer way to encode file-names that won't be absolutely horrible
to type. That would allow you to by hand disambiguate this sort of name collision. This
would also useful for accessing static variables in files & functions.
The expression parser does have some precedence order to deal with multiple
symbols of the same name. For instance, if there is one version in the dylib
containing the current source file and others out in the world, we will pick
the one in the containing dylib. If the function is actually implemented in
the compilation unit that holds the current frame, we should know to use that
one and not the others. We'd have to have debug info to be able to determine
this. If that's not working, then that shouldn't be hard to fix. But if
there are just a bunch of implementations in the same dylib but not in the
current compilation unit, there's no reasonable distance metric to use to
determine precedence.
Jim
On Jun 29, 2016, at 4:57 AM, Aidan via lldb-dev <lldb-dev@lists.llvm.org> wrote:
Hi all,
We have a process that contains multiple definitions of the same function. The
function in question is declared 'static extern' in a header and included in
multiple compilation units.
This causes some confusion for lldb expression parser when trying to invoke the
function by name, since it doesn't know which of the multiple (identical)
implementations to call. In this case the expression evaluation fails and
informs the user 'call to 'abs' is ambiguous' in my case.
The function in question could be changed to resolve the error, but I'd be
interested to know if there is a way to resolve such an ambiguity from the
LLDB's CLI.
Alternatively, should there be an precedence order that LLDB could be made to
obey in the case of this ambiguity?
Thanks,
Aidan
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
