Skip to content
Commit 12ba733c authored by Greg Clayton's avatar Greg Clayton
Browse files

When we have a symbol, like "NSLog" that we try to call in an expression, make...

When we have a symbol, like "NSLog" that we try to call in an expression, make sure we prioritize the external symbols over the internal one.

This is a temporary fix until a more comprehensive fix can be made for finding functions that we call in expressions.

We find "NSLog" in ClangExpressionDeclMap::FindExternalVisibleDecls() in after a call to target->GetImages().FindFunctions(...). Note that there are two symbols: NSLog from CFNetwork which is not external, and NSLog from Foundation which _is_ external. We do something with the external symbol with:

                    if (extern_symbol)
                    {
                        AddOneFunction (context, NULL, extern_symbol, current_id);
                        context.m_found.function = true;
                    }

Then later we try to lookup the _Z5NSLogP8NSStringz name and we don't find it so we call ClangExpressionDeclMap::GetFunctionAddress() with "_Z5NSLogP8NSStringz" as the name and the sc_list_size is zero at the "if" statement at line 568 because we don't find the mangled name and we extract the basename "NSLog" and call:

            FindCodeSymbolInContext(ConstString(basename), m_parser_vars->m_sym_ctx, sc_list);
            sc_list_size = sc_list.GetSize();

and we get a list size of two again, and we proceed to search for the symbol again, this time ignoring the external vs non-external-ness of the symbols that we find. This fix ensures we prioritize the external symbol until we get a real fix from Sean Callanan when he gets back to make sure we don't do multiple lookups for the same symbol we already resolved.

<rdar://problem/19879282>

llvm-svn: 231420
parent 28d94b1d
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment