Beside turning the options into the new tablegen format, this patch
also fixes that a few commands had source file completions for the
"count" and "end-linenumber" arguments (which both accepted only
integers). Reason for that are that somehow we added a '1' instead
of our usual '0' value to the initial value for completion.
llvm-svn: 366425
We currently emit the option groups twice if Groups<[1,2,3]> is
used in the tablegen. This leads to compilation errors. This
patch just removes the line that accidentially emits the option
group a second time.
llvm-svn: 366414
Summary:
When doing standalone builds, you could potentially be building against
an llvm which also built lldb. If this were the case, you'd be
attempting to build this target twice.
Reviewers: xiaobai
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D64847
llvm-svn: 366394
TableGen is a host tool and requires a native variant for every build.
While building as a part of llvm this is trivial and llvm handles it.
However, building standalone means that lldb has to handle this itself.
Add a NATIVE build variant to enable this.
llvm-svn: 366392
If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command. In that
case, we should try to find the binary and dSYM for the UUID
listed. The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.
The test case is a little involved,
1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
return the full path to the a.out + a.out.dSYM when called
with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
load command from the corefile, calling dsym-for-uuid.sh with
that UUID, got back the path to a.out and loaded it.
whew!
<rdar://problem/47562911>
llvm-svn: 366378
In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.
Differential Revision: https://reviews.llvm.org/D64777
llvm-svn: 366365
While the in-place hints on valid formats are up to date (e.g. when
choosing an invalid format expr -f nonExisting -- 42), the corresponding
online docs table is not. The formats "address", "hex float",
"instruction" and "void" are missing, and "decimal" refers to an
outdated abbreviation 'i' instead of 'd'.
Patch by: Lukas Böger
Differential revision: https://reviews.llvm.org/D63813
llvm-svn: 366364
I'm pretty sure there's no need to have this logic living in
LLDBStandalone. It doesn't appear anything in LLVM depends on this, and
We always go through LLDBConfig.cmake which has the canonical way to
find the Python libs and interpreter for LLDB.
Differential revision: https://reviews.llvm.org/D64821
llvm-svn: 366363
When doing a standalone build, without setting LLDB_PATH_TO_LLVM_BUILD
or LLDB_PATH_TO_CLANG_BUILD, you get the following error.
```
CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package):
Could not find a package configuration file provided by "LLVM" with any of
the following names:
LLVMConfig.cmake
llvm-config.cmake
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.
```
This suggests setting LLVM_DIR to LLVM's install directory. However,
LLDBStandalone.cmake takes LLDB_PATH_TO_LLVM_BUILD as its hint. As
someone who isn't familiar with the standalone process, this is rather
confusing. This patch removes LLDB_PATH_TO_LLVM_BUILD and
LLDB_PATH_TO_CLANG_BUILD and instead use LLVM_DIR and Clang_DIR
respectively.
Differential revision: https://reviews.llvm.org/D64823
llvm-svn: 366362
Disable colors so we don't risk having unexpected ANSI codes in the test
output. Currently, the behavior of a test can change depending on
whether it's run under a color-supporting terminal, or under a dummy
terminal, for example when using lit or multiprocessing.
llvm-svn: 366356
This genex created an order-only dependency to liblldb for every framework tool. It reduced build throughput in the first half of the compilation and pulled in unnecessary build units, e.g. debugserver required ~900 build units. With this change debugserver is (again) down at 52 build units!
llvm-svn: 366350
Summary:
Currently the ClangModulesDeclVendor is spamming the expression log with the compiler flags it is using, which creates a log that looks like this:
```
clang
-fmodules
-fimplicit-module-maps
```
This patch removes all these newlines and just prints the compiler flags in one line as you see in the command line:
```
clang -fmodules -fimplicit-module-maps [...]
```
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: davide, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64858
llvm-svn: 366347
By moving the standalone check into the main CMake file, the whole file
is ignored in a regular (non-standalone) build. This means that you can
make changes to LLDBStandalone.cmake without having to reconfigure a
build in a different directory. This matters when you share one source
repository with different build directories (e.g. release-assert, debug,
standalone).
Differential revision: https://reviews.llvm.org/D64824
llvm-svn: 366346
Summary:
A common transformation in NativePDB is to go from lldb types to clang
types and vice versa. This function automates one of those steps.
Differential Revision: https://reviews.llvm.org/D64851
llvm-svn: 366345
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage. The solution is to use noload_lookup, which
works well with transparent contexts. But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.
These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().
We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.
Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61333
llvm-svn: 366325
Summary:
We intend to make PdbAstBuilder abstract and implement
PdbAstBuilderClang along with any other languages that wish to use
PDBs. This is the first step.
Differential Revision: https://reviews.llvm.org/D64852
llvm-svn: 366293
Summary:
While cross compiling, the python executable is used to run a handful
of scripts while the libraries are linked and headers are included.
Theoretically it's possible for the versions to match completely, but
requiring the build to match 2.7.10 to 2.7.15 is unnecessary.
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D64822
llvm-svn: 366285
Summary:
ReadFile on Windows is supposed to set ERROR_OPERATION_ABORTED according
to the docs on MSDN. However, this has evidently been a known bug since
Windows 8. Therefore, we can't detect if a signal interrupted in the
fgets. So pressing ctrl-c causes the repl to end and the process to
exit. A temporary workaround is just to attempt to fgets twice until
this bug is fixed.
A possible alternative would be to set a flag in the `sigint_handler`
and simply check that flag in the true part of the if statement.
However, signal handlers on Windows are asynchronous and this would
require sleeping on the repl loop thread while still not necessarily
guarnateeing that you caught the sigint.
Reviewers: jfb
Differential Revision: https://reviews.llvm.org/D64660
llvm-svn: 366281
Because of how CMake finds the Python libraries and interpreter, it's
possible to end up with a discrepancy between the two. For example,
you'd end up using a Python 3 interpreter to run the test suite while
LLDB was built and linked against Python 2.
This patch adds a fatal error to CMake so we find out at configuration
time, instead of finding out at test time.
Differential revision: https://reviews.llvm.org/D64812
llvm-svn: 366243
The last swig 1.x release dates from 2009, now 10 years ago. Recently, I
fixed an issue that prevented us from using swig 4 (r364974), which
turned out to be not backward compatible with swig 1.x (r365718).
This patch deprecates this (really old) version of swig and makes swig 2
the minimum supported version in LLDB . This should be fine for the
build bots, which are all running swig 3 or later.
Differential revision: https://reviews.llvm.org/D64782
llvm-svn: 366213
It seems having two Options.inc files in the same project is giving our
custom Xcode project a hard time. This patch renames the new Options.inc
to CommandOptions.inc to prevent this conflict.
llvm-svn: 366196
Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.
Reviewers: JDevlieghere, compnerd, jingham, clayborg
Subscribers: mgorny, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D64763
llvm-svn: 366148
Summary: This patch adds documentation that should make it easier to migrate from using the old initializers to the table gen format.
Reviewers: jingham
Reviewed By: jingham
Subscribers: abidh, lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64670
llvm-svn: 366083
This needs to be outside the if to actually work. Also, this adjusts the
list of versions to match LLVM.
Patch by: Christian Biesinger
Differential revision: https://reviews.llvm.org/D64578
llvm-svn: 365988
Summary: This seems better suited to be in a plugin.
Reviewers: JDevlieghere, clayborg, jingham, compnerd, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64599
llvm-svn: 365951
Summary:
Instead of hardcoding ClangASTContext and ObjCLanguageRuntime, we can
generalize this by creating the method GetRuntimeType in
LanguageRuntime and moving the current MaybeCalculateCompleteType
implementation into ObjCLanguageruntime::GetRuntimeType
Reviewers: jingham, clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D64159
llvm-svn: 365939
Summary:
We currently have man large arrays containing initializers for our command options.
These tables are tricky maintain as we don't have any good place to check them for consistency and
it's also hard to read (`nullptr, {}, 0` is not very descriptive).
This patch fixes this by letting table gen generate those tables. This way we can have a more readable
syntax for this (especially for all the default arguments) and we can let TableCheck check them
for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.).
Also refactoring the related data structures can now be done without changing the hundred of option initializers.
For example, this line:
```
{LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."},
```
becomes this:
```
def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">;
```
For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other
option initializers tables in separate patches.
Reviewers: JDevlieghere, davide, sgraenitz
Reviewed By: JDevlieghere
Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64365
llvm-svn: 365908
Summary:
Windows requires re-setting the signal handler each time it is used
and thus ctrl-c was not behaving properly on Windows
Reviewers: jfb
Differential Revision: https://reviews.llvm.org/D64046
llvm-svn: 365868
Summary:
IRDynamicChecks in its current form is specific to Clang since it deals
with the C language family. It is possible that we may want to
instrument code generated for other languages, but we can factor in a
more general mechanism to do so at a later time.
This decouples ObCLanguageRuntime from Expression!
Reviewers: compnerd, clayborg, jingham, JDevlieghere
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64591
llvm-svn: 365853
This patch adds two convenience methods named GetAsLLVM to the LLDB
counterparts of the DWARF DataExtractor and the DWARF context. The
DWARFContext, once created, is cached for future usage.
Differential revision: https://reviews.llvm.org/D64535
llvm-svn: 365819
Summary:
It seems that calling Popen can return to the caller before the started process has read all the needed information
from its executable. This means that in case we delete the executable while the process is still starting up,
this test will create a zombie process which in turn leads to a failing test. On my macOS system this happens quite frequently.
This patch fixes this by letting the test synchronize with the inferior after it has started up.
Reviewers: davide
Reviewed By: davide
Subscribers: labath, friss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64546
llvm-svn: 365813
Raphael Isemann