llvm-project/lldb/lit/lit.site.cfg.in

33 lines
1.3 KiB
INI
Raw Normal View History

@LIT_SITE_CFG_IN_HEADER@
config.llvm_src_root = "@LLVM_SOURCE_DIR@"
config.llvm_obj_root = "@LLVM_BINARY_DIR@"
config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
config.lldb_obj_root = "@LLDB_BINARY_DIR@"
config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
config.target_triple = "@TARGET_TRIPLE@"
config.python_executable = "@PYTHON_EXECUTABLE@"
config.cc = "@LLDB_TEST_C_COMPILER@"
config.cxx = "@LLDB_TEST_CXX_COMPILER@"
config.have_zlib = @LLVM_ENABLE_ZLIB@
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
2018-05-03 18:57:16 +08:00
config.have_lld = @LLDB_HAVE_LLD@
# Support substitution of the tools and libs dirs with user parameters. This is
# used when we can't determine the tool dir at configuration time.
try:
config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
config.cc = config.cc % lit_config.params
config.cxx = config.cxx % lit_config.params
except KeyError as e:
key, = e.args
lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))
# Let the main config do the real work.
lit_config.load_config(config, "@LLDB_SOURCE_DIR@/lit/lit.cfg")