forked from OSchip/llvm-project
5 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
![]() |
58db03a116 |
Fix some issues with LLDB's lit configuration files.
Recently I tried to port LLDB's lit configuration files over to use a on the surface, but broke some cases that weren't broken before and also exposed some additional problems with the old approach that we were just getting lucky with. When we set up a lit environment, the goal is to make it as hermetic as possible. We should not be relying on PATH and enabling the use of arbitrary shell commands. Instead, only whitelisted commands should be allowed. These are, generally speaking, the lit builtins such as echo, cd, etc, as well as anything for which substitutions have been explicitly set up for. These substitutions should map to the build output directory, but in some cases it's useful to be able to override this (for example to point to an installed tools directory). This is, of course, how it's supposed to work. What was actually happening is that we were bringing in PATH and LD_LIBRARY_PATH and then just running the given run line as a shell command. This led to problems such as finding the wrong version of clang-cl on PATH since it wasn't even a substitution, and flakiness / non-determinism since the environment the tests were running in would change per-machine. On the other hand, it also made other things possible. For example, we had some tests that were explicitly running cl.exe and link.exe instead of clang-cl and lld-link and the only reason it worked at all is because it was finding them on PATH. Unfortunately we can't entirely get rid of these tests, because they support a few things in debug info that clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record which makes some of the tests fail. The high level changes introduced in this patch are: 1. Removal of functionality - The lit test suite no longer respects LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no more support for gcc, but nobody was using this anyway (note: The functionality is still there for the dotest suite, just not the lit test suite). There is no longer a single substitution %cxx and %cc which maps to <arbitrary-compiler>, you now explicitly specify the compiler with a substitution like %clang or %clangxx or %clang_cl. We can revisit this in the future when someone needs gcc. 2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now more friendly. If this is not specified, all tools are expected to be the just-built tools. If it is specified, the tools which are not themselves being tested but are being used to construct and run checks (e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this directory first, then the build output directory. 3. Changes to core llvm lit files. The use_lld() and use_clang() functions were introduced long ago in anticipation of using them in lldb, but since they were never actually used anywhere but their respective problems, there were some issues to be resolved regarding generality and ability to use them outside their project. 4. Changes to .test files - These are all just replacing things like clang-cl with %clang_cl and %cxx with %clangxx, etc. 5. Changes to lit.cfg.py - Previously we would load up some system environment variables and then add some new things to them. Then do a bunch of work building out our own substitutions. First, we delete the system environment variable code, making the environment hermetic. Then, we refactor the substitution logic into two separate helper functions, one which sets up substitutions for the tools we want to test (which must come from the build output directory), and another which sets up substitutions for support tools (like compilers, etc). 6. New substitutions for MSVC -- Previously we relied on location of MSVC by bringing in the entire parent's PATH and letting subprocess.Popen just run the command line. Now we set up real substitutions that should have the same effect. We use PATH to find them, and then look for INCLUDE and LIB to construct a substitution command line with appropriate /I and /LIBPATH: arguments. The nice thing about this is that it opens the door to having separate %msvc-cl32 and %msvc-cl64 substitutions, rather than only requiring the user to run vcvars first. Because we can deduce the path to 32-bit libraries from 64-bit library directories, and vice versa. Without these substitutions this would have been impossible. Differential Revision: https://reviews.llvm.org/D54567 llvm-svn: 347216 |
|
![]() |
023bdc6148 |
lit/SymbolFile/DWARF: Simplify test RUN lines
Use -mllvm compiler argument to enable DWARF v5 accelerator tables instead of piping the IR through llc. llvm-svn: 334496 |
|
![]() |
e1d18758eb |
DebugNamesDWARFIndex: Add ability to lookup variables
Summary: This patch adds the ability to lookup variables to the DWARF v5 index class. During review we discovered an inconsistency between how the existing two indexes handle looking up qualified names of the variables: - manual index would return a value if the input string exactly matched the demangled name of some variable. - apple index ignored the context and returned any variable with the same base name. So, this patch also rectifies that situation: - it removes all context handling from the index classes. The GetGlobalVariables functions now just take a base name. For manual index, this meant we can stop putting demangled names into the variable index (this matches the behavior for functions). - context extraction is put into SymbolFileDWARF, so that it is common to all indexes. - additional filtering based on the context is also done in SymbolFileDWARF. This is done via a simple substring search, which is not ideal, but it matches what we are doing for functions (cf. Module::LookupInfo::Prune). Reviewers: clayborg, JDevlieghere Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D47781 llvm-svn: 334181 |
|
![]() |
bf5a3f8393 |
Add some apple-tables lookup tests
Summary: Now that we are able to parse MachO files everywhere, we can write some cross-platform tests for handling of apple accelerator tables. This reruns the same lookup tests we have for manual indexes on MachO files which will use the accelerator tables instead. This makes sure we return the same results regardless of the method we used to access the debug info. The tests confirm we return the same results for looking up types, namespaces and variables, but have found an inconsistency in the treatment of function lookup. In the function case we mis-classify the method "foo" declared in the local struct sbar (inside function ffbar). We classify it as a function whereas it really is a method. Preliminary analysis suggests this is because DWARFASTParserClang::GetClangDeclContextForDIE returns null when given the local "struct sbar" DIE. This causes us to get the wrong CompilerDeclContext when we ask for the context of the inner foo, which means CompilerDeclContext::ISStructUnionOrClass returns false. Until this is fixed, I do not include the darwin versions of the "base" and "method" function lookup tests. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits Differential Revision: https://reviews.llvm.org/D47064 llvm-svn: 332831 |
|
![]() |
90b0a53499 |
lldb-test symbols: Add ability to do name-based lookup
Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447 |