llvm-project

Commit Graph

Author	SHA1	Message	Date
Zachary Turner	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	2018-11-19 15:12:34 +00:00
Pavel Labath	3ca31ba75a	AppleDWARFIndex: Get function method-ness directly from debug info Summary: When searching for methods only, we need to do extra work to make sure the functions we get from the apple tables are indeed methods. Previously we were resolving the DIE into a SymbolContext and then checked whether the enclosing CompilerDeclContext is a class (or struct, or union). This patch changes that to operate on the debug info directly. This should be: - simpler - faster - more consistent with the ManualDWARFIndex (which does the same check, only at indexing time). What we lose this ways is for the language plugin to have a say in what it considers to be a "class", but that's probably more flexibility than we need (and if we really wanted to do that in the future, we could implement a more direct way to consult the plugin about this). This also fixes the find-method-local-struct test, which was failing because we were not able to construct a CompilerDeclContext for a local struct correctly. As a drive-by, I rename the DWARFDIE's IsStructClassOrUnion method to match the name on the CompilerDeclContext class. Reviewers: clayborg, JDevlieghere Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D47470 llvm-svn: 333878	2018-06-04 09:05:27 +00:00
Pavel Labath	becc204633	Improve coverage of the apple-tables test After closer examination, it turns out we mis-classify one of the methods only if two of the structs have the same name. Since this was meant to be a basic test, I rename one of the structs in the test so that we have at least some coverage for the apple tables lookup. Instead, I create an XFAILed test which specifically targets the same-name case (and file a bug to track it). llvm-svn: 332833	2018-05-21 10:09:22 +00:00

Author

SHA1

Message

Date

Zachary Turner

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

2018-11-19 15:12:34 +00:00

Pavel Labath

3ca31ba75a

AppleDWARFIndex: Get function method-ness directly from debug info

Summary:
When searching for methods only, we need to do extra work to make sure
the functions we get from the apple tables are indeed methods.
Previously we were resolving the DIE into a SymbolContext and then
checked whether the enclosing CompilerDeclContext is a
class (or struct, or union).

This patch changes that to operate on the debug info directly. This
should be:
- simpler
- faster
- more consistent with the ManualDWARFIndex (which does the same check,
  only at indexing time).

What we lose this ways is for the language plugin to have a say in what
it considers to be a "class", but that's probably more flexibility than
we need (and if we really wanted to do that in the future, we could
implement a more direct way to consult the plugin about this).

This also fixes the find-method-local-struct test, which was failing
because we were not able to construct a CompilerDeclContext for a local
struct correctly.

As a drive-by, I rename the DWARFDIE's IsStructClassOrUnion method to
match the name on the CompilerDeclContext class.

Reviewers: clayborg, JDevlieghere

Subscribers: aprantl, lldb-commits

Differential Revision: https://reviews.llvm.org/D47470

llvm-svn: 333878

2018-06-04 09:05:27 +00:00

Pavel Labath

becc204633

Improve coverage of the apple-tables test

After closer examination, it turns out we mis-classify one of the
methods only if two of the structs have the same name. Since this was
meant to be a basic test, I rename one of the structs in the test so
that we have at least some coverage for the apple tables lookup.
Instead, I create an XFAILed test which specifically targets the
same-name case (and file a bug to track it).

llvm-svn: 332833

2018-05-21 10:09:22 +00:00

3 Commits