HomePhabricator

Search variables based on clang::DeclContext and clang::Decl tree
AuditedrL247746

Description

Search variables based on clang::DeclContext and clang::Decl tree

Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.

Reviewers: sivachandra, chaoren, spyffe, clayborg

Subscribers: tberghammer, jingham, lldb-commits

Differential Revision: http://reviews.llvm.org/D12658

Details

Auditors
dawn
Committed
paulhermanSep 15 2015, 4:44 PM
Differential Revision
D12658: Search variables based on clang::DeclContext and clang::Decl tree
Parents
rL247745: [elf2] Add error checking for the R_X86_64_32 relocation.
Branches
Unknown
Tags
Unknown

Event Timeline

dawn raised a concern with this commit.Sep 29 2015, 1:03 PM
dawn added a subscriber: dawn.

This commit caused a regression when evaluating globals inside a namespace. See comments in the following narrowed test case. Can you have a look please? (Note: test case was tested with clang based on svn 3.4, 3.6 and trunk on OSX). Thanks!

#include <stdio.h>
int make_used;
static int ScNSpacGl = 2100;
namespace NS2 {
    static int ScNSpacGl = 2111;
    static void NS2Func(void) {
        // BP2, eval ::ScNSpacGl, Exp: 2100 Act: 2111, caused by commit 28746fe (svn.247746)
        printf("eval @BP2 line=%d: ::ScNSpacGl = %d\n", __LINE__, ::ScNSpacGl);
        make_used += ScNSpacGl;
    }
}
int main(int argc, char **argv) {
    NS2::NS2Func();
    return make_used == 0;
}

Calling this a regression is probably harsh. Without looking into it much, my feeling here is that Clang (the LLDB compiler) does not ask for the value ScNSpacGl in the global namespace, but just for a value named ScNSpacGl. In which case, LLDB (after this change), returns the most meaningful value for the context to Clang. Before this change, LLDB returned, in a way, the first "global" value it found with name "ScNSpacGl". I put "global" in quotes because, the variables in question here are in different semantic scopes, but physically have a "global" layout in memory. So, if we had done this:

(lldb) p ScNSpacGl

before this change, LLDB would have printed the value of the global var not that of in the namespace. Now it prints the value of the one in the namespace.

dawn accepted this commit.Sep 29 2015, 5:44 PM

Clang (the LLDB compiler) does not ask for the value ScNSpacGl in the global namespace, but just for a value named ScNSpacGl.

Ok, I've opened a separate bug for this then, https://llvm.org/bugs/show_bug.cgi?id=24994.