[lldb-dev] Calling multiply defined symbols

[Jim Ingham via lldb-dev]

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 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev