Instead of taking a status and potentially returning an invalid address,
return an expected which is guaranteed to contain a valid address.
llvm-svn: 366521
Windows does not have the error EINTR when a blocking syscall is
interrupted by a signal. The ReadFile API that fgets is implemented
with instead use ERROR_OPERATION_ABORTED. Check for that after fgets.
llvm-svn: 366520
Summary:
LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with
{LLVM,Clang}_DIR. Adjust the NATIVE build to account for this.
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D64959
llvm-svn: 366513
When two .c files define a type of the same name, lldb
just picks one and uses it regardless of context. That is
not correct. When stopped in a frame in one of the .c files
that define this type, it should use that local definition.
This commit just adds a test that checks for the correct
behavior. It is currently xfailed.
llvm-svn: 366507
the xcode project. This gets it a little closer to
working, but I still have to figure out how to generate
the lldb tablegen backend from the Xcode project.
llvm-svn: 366506
The new DriverKit user-land kernel drivers in macOS 10.15 / Catalina
do not have a main() function or an LC_MAIN load command. lldb uses
the address of main() as the return address for inferior function
calls; it puts a breakpoint on main, runs the inferior function call,
and when the main() breakpoint is hit, lldb knows unambiguously that
the inferior function call ran to completion - no other function calls
main.
This change hoists the logic for finding the "entry address" from
ThreadPlanCallFunction to Target. It changes the logic to first
try to get the entry address from the main executable module,
but if that module does not have one, it will iterate through all
modules looking for an entry address.
The patch also adds code to ObjectFileMachO to use dyld's
_dyld_start function as an entry address.
<rdar://problem/52343958>
Differential Revision: https://reviews.llvm.org/D64897
llvm-svn: 366493
Instead of having to write FileSpecList::Append(FileSpec(args)) you can
now call FileSpecList::EmplaceBack(args), similar to
std::vector<>::emplace_back.
llvm-svn: 366489
r366471 added "-features autodoc" without a trailing comment, leading to `Unrecognized option -features autodoc-threads` due to implicit string concatenation. Add a comma to fix that.
Also separate into "-features" and "autodoc", otherwise it gets parsed as a single "-features autodoc" flag which is also not recognized (it must be two separate CLI args).
llvm-svn: 366478
Summary:
We currently don't support offsetof in the expression evaluator as it is implemented as a macro
(which then calls __builtin_offsetof) in stddef.h. The best solution would be to include that
header (or even better, import Clang's builtin module), but header-parsing and
(cross-platform) importing modules is not ready yet.
Until we get this working with modules I would say we add the macro to our existing macro list
as we already do with other macros from stddef.h/stdint.h. We should be able to drop all of them
once we can import the relevant modules by default.
rdar://26040641
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64917
llvm-svn: 366476
Summary:
We can always build debugserver, but we can't always sign it to be useable for testing. `LLDB_USE_SYSTEM_DEBUGSERVER` should only tell whether or not the system debugserver should be used for testing.
The old behavior complicated the logic around debugserver a lot. The new logic sorts out most of it.
Please note that this patch is in early stage and needs some more testing. It should not affect platfroms other than Darwin. It builds on Davide's approach to validate the code-signing identity at configuration time.
What do you think?
Reviewers: xiaobai, JDevlieghere, davide, compnerd, friss, labath, mgorny, jasonmolenda
Reviewed By: JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64806
llvm-svn: 366433
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
Summary:
I saw while debugging that we call this file `ParseInternal`, which is not a very good name for our
fake expression file and also adds this unnecessary link between the way we name this function
and the other source location names we get from the expression parser. This patch is renaming
it to `<lldb-expr>` which is closer to the way Clang names its buffers, it doesn't depend on the
function name (which changes when I refactor this code) and it's easier to grep for.
Reviewers: davide
Reviewed By: davide
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64545
llvm-svn: 365812
It seems on Windows we don't handle the lldb_expr_result variable correctly:
```
AssertionError: False is not True : 'expr $__lldb_expr_result' returns expected result, got '(int &) $0 = 0x0000000000000000'
```
I'll disable the test until I can find a way to debug this on Windows.
llvm-svn: 365719
Apparently, when using swig 1.3.40, properties to set values do not work
without the `__swig_setmethods__` workaround. I conditionally added this
back for SBTypeCategory, as it's causing a test failure on GreenDragon,
while I investigate this further.
llvm-svn: 365718
Right now, IR Instrumenters take a DynamicCheckerFunctions object which
has all the UtilityFunctions used to instrument IR for expressions.
However, each Instrumenter (in practice) uses exactly one
UtilityFunction, so let's change the abstraction.
llvm-svn: 365696
Python 3.6 and 3.7 have been released.
Differential Revision: https://reviews.llvm.org/D64444
Patch from Christian Biesinger <cbiesinger@google.com>!
llvm-svn: 365688
There are pre-made utilities doing this. If somebody finds an
use for it and wants to resurrect, I would recommend to revise
the error messages.
llvm-svn: 365677
Summary:
While investigating breakages caused by D63110, I noticed we were
building the short options strings in three places. Some of them used a
leading ':' to detect missing arguments, and some didn't. This was the
indirect cause of D63110. Here, I move the common code into a utility
function.
Also, unify the code which appends the sentinel value at the end of the
option vector, and make it harder for users to pass invalid argc-argv
combos to getopt (another component of D63110) by having the
OptionParser::Parse function take a (Mutable)ArrayRef.
This unification has uncovered that we don't handle missing arguments
while building aliases, However, it's not possible to write an effective
test for this, as right now it is not possible to return an error out of
the alias parsing code (which means we are printing the generic
"failure" message even after this patch).
Reviewers: mgorny, aprantl
Reviewed By: mgorny
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63770
llvm-svn: 365665
With this style, a compressed section is indicated by a "z" in the section
name, instead of a section header flag. This patch consists of two small tweaks:
- use an llvm Decompressor method in order to properly detect compressed sections
- make sure we recognise .zdebug_info (and friends) when classifying section types.
llvm-svn: 365654
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
Summary: The custom lldb-framework target was meant to encapsulate all build steps that LLDB.framework needs on top of the ordinaly liblldb. In the end all of it happens in post-build steps, so we can do the same with liblldb and cut down another source of confusion.
Reviewers: xiaobai, JDevlieghere
Reviewed By: xiaobai, JDevlieghere
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64397
llvm-svn: 365615
Summary:
Move checking pointer code block before accessing the pointer
This caused lldb to crash when testing on Android
Patch by Wanyi Ye!
Differential Revision: https://reviews.llvm.org/D64434
llvm-svn: 365567
Summary:
Fixed `Android.rules` for running test suite on remote android
- the build configuration is not compatible with ndk structure, change it to link to static libc++
- generally clang should be able to use libc++ and will link against the right library, but some libc++ installations require the user manually link libc++abi.
- add flag `-lc++abi` to fix the test binary build failure
Added `skipIfTargetAndroid` `skipUnlessTargetAndroid` for better test support
- the `skipIfPlatform` method will ask `lldbplatformutil.getPlatform()` for platform info which is actually the os type, and //Android// is not os type but environment
- create this function to handle the android target condition
**To Run Test on Remote Android**
1 start lldb-server on your devices
2 run lldb-dotest with following configuration:
`./lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:12345 --platform-working-dir /data/local/tmp/ --compiler your/ndk/clang`
Reviewers: xiaobai, labath
Reviewed By: labath
Subscribers: labath, javed.absar, kristof.beyls, srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64118
llvm-svn: 365561
Summary: Replaces references to svn commits with the lldb version number those commits first appeared in. Themotivation is to show that these features are no longer that new and can generally be adopted.
Reviewers: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61778
llvm-svn: 365559
This test was originally marked as expected failure on Windows, but it is timing out instead of outright failing now. The expectedFailure attribute does not correctly track timeouts (as in, they don't count as failures), so now this is causing the test suite to fail.
llvm-svn: 365527
After discussing this internally, it is my understanding this was used
for building LLDB internally at Apple, and is no longer used or
necessary.
llvm-svn: 365392
As discussed offline, this tool is no longer used or maintained, and
doesn't provide the right abstraction for performance tracking in lldb.
Differential revision: https://reviews.llvm.org/D64362
llvm-svn: 365391
The Windows build currently cannot support debugging foreign targets or
debugging Windows ARM NT and Windows ARM64 targets. Do not assume a
x64/x86 host. This enables building lldb for Windows ARM64.
llvm-svn: 365282
We had a long discussion in D59911 about lldb_assert and what it means.
The result was the assert manifesto on lldb.llvm.org.
> LLDB provides lldb_assert() as a soft alternative to cover the middle
> ground of situations that indicate a recoverable bug in LLDB. In a
> Debug configuration lldb_assert() behaves like assert(). In a Release
> configuration it will print a warning and encourage the user to file a
> bug report, similar to LLVM’s crash handler, and then return
> execution.
However, currently lldb_assert doesn't behave they way it's being
described there: it doesn't abort in a debug/assert build. This patch
fixes that by adding a call to assert() in lldb_assert().
Differential revision: https://reviews.llvm.org/D64267#1571962
llvm-svn: 365246
Change the interface to return an expected, instead of taking a Status
pointer.
Differential revision: https://reviews.llvm.org/D64163
llvm-svn: 365226
Summary:
If we call this function with a non-namespace as a second argument (and a nullptr name), we currently
only get a nullptr as a return when we hit the "Bad!!!" code path. This patch just adds an assert as this
seems to be a programming error in the calling code.
Reviewers: shafik
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57880
llvm-svn: 365157
Rather than relying on `sizeof(void *)` to determine the architecture,
use the `CMAKE_SYSTEM_PROCESSOR` variable. This should allow us to
build for Windows and cross-compile. Without this, we would attempt to
build the x64 plugin on ARM64 which would fail due to the `CONTEXT` type
being defined for ARM64 rather than `x64`.
llvm-svn: 365155
Summary: This patch modernizes the GetSDKVersion API and hopefully prevents problems such as the ones discovered in D61218.
Reviewers: aprantl, jasonmolenda, clayborg
Reviewed By: aprantl, clayborg
Subscribers: clayborg, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61233
llvm-svn: 365090
The current build instructions are structured according the host
platform. Instead of having instructions on how to build with CMake
repeated for every platform, I unified them, using subsections if things
are different for between platforms. I also added the code signing
instructions, which were hidden in a text file in the repository.
llvm-svn: 365081
Summary:
This option allow the toggling of the libraries-svr4 usage in ProcessGDBRemote. It's a follow up of https://reviews.llvm.org/D62503#1564296 and it's meant to test / tweak this new packet with, hopefully, minimum impact and in a faster way.
Enable it with `settings set plugin.process.gdb-remote.use-libraries-svr4 true`. For now, by default it's false.
I didn't put tests up for this but I did test it manually.
Reviewers: labath, jankratochvil
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64112
llvm-svn: 365059
libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship `libc++.dylib` and/or `libc++.a`). Disable the respective link steps to avoid the dependency to libc++abi.
<rdar://problem/51980716>
llvm-svn: 365038
This was set in a std::function, but I was shadowing a
variable that I thought I was capturing. Even with this bug
we were correctly not raising an error and returning an address
of 0x0. We were not marking the symbol as weak, but apparently
the JIT didn't need that, so the test still passed.
llvm-svn: 364980
As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no
longer defined. It appears that there's no need to mess with these
internals, we can simplify define the corresponding properties inline.
Originally I wanted to use the swig extension %attribute and
%attributeref to define properties. However, I couldn't find a way to
add documentation to these attributes. Since we already had the
properties defined inline, we might as well keep them.
Differential revision: https://reviews.llvm.org/D63530
llvm-svn: 364974
The script is the modern way of getting the certificate, so we should mention it in
the documentation.
Patch idea by Davidino Italiano!
llvm-svn: 364967
Summary:
Following up on the plan I outlined in D63622, we can remove the
dependence on clang in all the places where we only want to find the
types from the DeclVendor. This means that currently DeclVendor depends
on clang, but centralizing the dependency makes it easier to refactor
cleanly.
Differential Revision: https://reviews.llvm.org/D63853
llvm-svn: 364962
As of SWIG 4.0, __swig_getmethods__ and __swig_setmethods__ are no
longer defined. The solution is to stop using these internal swig
dictionaries and use %attribute and %attributeref instead. I plan on
doing this incrementally, with this differential serving as an example.
Differential revision: https://reviews.llvm.org/D63530
llvm-svn: 364946
It looks like when this test was added, it was based on TestHelloWorld and it ended up with the same class name. This is an issue because the logs associated with the tests use the class name as the identifier for the file and if two tests have the same name their logs overwrite each other. On non-windows, this just means we lose one of the logs, but on Windows this means that one of the tests will fail occasionally because the file are locked by the other test.
llvm-svn: 364860
I'm not able to reproduce the reproducer flakiness we're seeing on
GreenDragon. I want to add this assert to find out if the GDB remote
packets are somehow getting out of sync when this happens.
llvm-svn: 364852
Summary:
Instead of falling back to ObjCLanguageRuntime, we should be falling
back to every loaded language runtime. This makes ValueObject more
language agnostic.
Reviewers: labath, compnerd, JDevlieghere, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63240
llvm-svn: 364845
It looks like when this test was added, it was based on TestBreakAfterJoin and it ended up with the same class name. This is an issue because the logs associated with the tests use the class name as the identifier for the file and if two tests have the same name their logs overwrite each other. On non-windows, this just means we lose one of the logs, but on Windows this means that one of the tests will fail occasionally because the file are locked by the other test.
llvm-svn: 364826
Set global enable bits (i.e. bits 1, 3, 5, 7) to enable watchpoints
on NetBSD rather than the local enable bits (0, 2, 4, 6). The former
are necessary for watchpoints to be correctly recognized by the NetBSD
kernel. The latter cause them to be reported as trace points.
Differential Revision: https://reviews.llvm.org/D63792
llvm-svn: 364781
Fix the watchpoint/breakpoint code to search for matching thread entry
in m_threads explicitly rather than assuming that it will be present
at specified index. The previous code segfault since it wrongly assumed
that the index will match LWP ID which was incorrect even for a single
thread (where index was 0 and LWP ID was 1).
While fixing that off-by-one error would help for this specific task,
I believe it is better to be explicit in what we are searching for.
Differential Revision: https://reviews.llvm.org/D63791
llvm-svn: 364780
Provide a (conditional) support for the new PT_GETXSTATE
and PT_SETXSTATE ptrace() requests, and use them to implement getting
and setting YMM registers. The functions used for splitting
and recombining YMM register data are based on matching functions
in FreeBSD plugin, with some simplification and updates to match NetBSD
structures.
Differential Revision: https://reviews.llvm.org/D63545
llvm-svn: 364779
A bunch of places were checking that DataBufferHeap::GetBytes returns a
non-null pointer right after constructing it. The only time when
GetBytes returns a null pointer is if it is empty (and I'm not sure that
even this is a good idea), but that is clearly not the case here, as the
buffer was constructed with a non-zero size just a couple of lines back.
llvm-svn: 364754
D62502, together with D62503 have broken the builds which have XML
support enabled. Reverting D62503 (r364355) fixed that, but has broken
has left some of the tests introduced by D62502 broken more or less
nondeternimistically (it depended on whether the system happens to place
the library list near unreadable pages of memory). I attempted to make a
partial fix for this in r364748, but Jan Kratochvil pointed out that
this reintroduces the problem which reverting D62503 was trying to
solve.
So instead, I back out the whole thing so we can get back to a clean
slate that works for everyone. We can figure out a way forward from
there.
This reverts r364748, r363772 and r363707.
llvm-svn: 364751
D62502 had a bug (visible only with D62503 reverted), where it would
error out if attempting to read a string from memory and the memory page
after the string happened to be unmapped.
This fixes the problem by checking for whether ReadMemory read *any*
bytes, instead of checking whether it returned an error. A greater
question is whether ReadMemory should even return an error if it read at
least one byte, but I'm leaving that for a separate patch.
llvm-svn: 364748
operator new doesn't return a null pointer, even if one turns off
exceptions (it calls std::terminate instead). Therefore, all of this is
dead code.
llvm-svn: 364744
The arbitrary timeout when flushing GDB remote packets caused
non-determinism and flakiness between test runs. I suspect it is what's
causing the flakiness of the reproducer tests on GreenDragon, and want
to see if removing it causes that to go away.
This change was originally introduced in r197579 to discard a
`$T02thread:01;#4` that QEMU was sending. If anybody knows how to test
that this continues working after removing this code, I'd love to hear
it.
llvm-svn: 364669
on a thread. When talking to some older gdb-remote stubs, We were getting
a stop reason from the stop reply packet and setting it on the relevant
thread before we updated the full stop list. That would get discarded when
the full list was updated.
Also, if you already have a thread list when you go to see if there is an
Operating System plugin, and you do indeed load a new OS plugin, you have to
re-fetch the thread list or it will only show the raw threads.
Differential Revision: https://reviews.llvm.org/D62887
llvm-svn: 364666
Reenable SysV x86_64 ABI usage on NetBSD that was accidentally removed
in r364216. This fixes numerous test failures with messages similar
to the following:
error: Can't run the expression locally: Interpreter doesn't handle
one of the expression's opcodes
llvm-svn: 364503
This fixes two replay issues that caused the tests to behave
erratically:
1. It fixes an off-by-one error, where all replies where shifted by 1
because of a `+` packet that should've been ignored.
2. It fixes another off-by-one-error, where an asynchronous ^C was
offsetting all subsequent packets. The reason is that we
'synchronize' requests and replies. In reality, a stop reply is only
sent when the process halt. During replay however, we instantly
report the stop, as the reply to packets like continue (vCont).
Both packets should be ignored, and indeed, checking the gdb-remote log,
no unexpected packets are received anymore.
Additionally, be more pedantic when it comes to unexpected packets and
return an failure form the replay server. This way we should be able to
catch these things faster in the future.
llvm-svn: 364494
The qemu x86_64 target returns a target.xml register definition file which
includes other xml files and they include others, etc. Also, the registers
are not put in register groups like lldb wants to see.
This patch (1) puts registers that aren't in a register group in a "general"
register group, (2) change ProcessGDBRemote::GetGDBServerRegisterInfo to
be a method that starts the parsing, asking a recurisve function to fetch
and parse target.xml, (3) adds
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess which can recusively
call itself to read and parse included xml files, (4) in addition to expecting
the top-level <target> element (which only happens in the top level xml file),
also an xml file that consists of a <feature> node - read the register
defintions and includes from that <feature> element.
<rdar://problem/49537922>
Differential revision: https://reviews.llvm.org/D63802
llvm-svn: 364484
Copy over access and modification time for the files included in the
reproducer. This is needed to pass tests that check the integrity of
object files based on their time stamp.
llvm-svn: 364457
This patch adds a dotest flag for setting environment variables for the
inferior. This is different from the current --env flag, which sets
variables in the debugger's environment. This allows us to set things
like LD_LIBRARY_PATH for testing.
Differential revision: https://reviews.llvm.org/D63790
llvm-svn: 364443
Unfortunately I had to work backwards from a crash log,
so I don't have a good testcase at this point in time.
rdar://problem/51874647
llvm-svn: 364344
Make sure the prompt has been flushed before reading commands. Buffering
is different in Python 3, which led to the prompt not being displayed in
the Xcode console.
llvm-svn: 364335
Relying on the value of optind for detecting missing arguments is
unreliable because its value after a failed parse is an implementation
detail. A more correct way to achieve this is to pass ':' at the
beginning of option string, which tells getopt to return ':' for missing
arguments.
For this to work, I also had to add a nullptr at the end of the argv
vector, as some getopt implementations did not work without that. This
is also an implementation detail, as getopt should normally be called
with argc+argc "as to main function" (i.e. null-terminated).
Thanks to Michał Górny for testing this patch out on NetBSD.
llvm-svn: 364317
Summary:
If target.preload-symbols is false, waiting for the process to "stop"
can take an arbitrarily long amount of time, because it will cause all
the debug info to be parsed (to compute the stop message showing the
function, its arguments, etc).
We were previously waiting for 10 seconds for the stop even to arrive,
which is a pretty long time, but it's not that hard to overcome with
huge debug info.
Since any arbitrary limit can be theoretically overcome with huge
debug_info and/or slow machine, and the stop even was sent 3 lines above
the wait, if we ever do not receive the stop even means we've got a bug
in lldb. Therefore, I remove the timeout on this wait completely.
No test because I don't know how to reproduce this without a
multi-gigabyte symbol file.
Reviewers: jingham, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D63730
llvm-svn: 364276
Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one
The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.
Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63643
llvm-svn: 364274
+ dlsym the two functions we need from there at runtime.
I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll try to dlopen() it on every call to
LocateMacOSXFilesUsingDebugSymbols but this file is only built on
mac and iOS type systems, so there's a slight perf impact running
lldb on an iOS type system.
I store the function pointer results in two global variables without
any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols
for the first time will both try to set these fptrs, but they'll be
setting them to the same value, so I'm not too worried.
I didn't see where in the cmake build configurations we link against
DebugSymbols, but I removed the dependency from the xcode project
file.
<rdar://problem/49458356>
llvm-svn: 364243
Summary:
It's possible that each LanguageRuntime could have its own DeclVendor,
so let's hoist that out of ObjCLanguageRuntime into LanguageRuntime.
Additionally, this gives the opportunity to remove SBTarget's dependency
on ObjCLanguageRuntime.
Reviewers: JDevlieghere, labath, compnerd, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63622
llvm-svn: 364229
Summary:
Implement the ABI for WIndows-x86_64 including register info and calling convention.
Handled nested struct returned in register (SysV doesn't have it supported)
Reviewers: xiaobai, compnerd
Reviewed By: compnerd
Subscribers: labath, jasonmolenda, fedor.sergeev, mgorny, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62213
llvm-svn: 364216
Summary:
This change extracts functionalities from processwindows into a
introduced processdebugger that can be reused in native process
debugging.
The main reason is that the native process debugging
can't directly be based on processwindows or be implemented
as a pass-through to this plugin since the plugin has ties to
Target and Process classes that are needed in host debugging but
not necessary in native debugging.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, dexonsmith, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63166
llvm-svn: 364210
This makes the `lit-lldb-init` file configurable by CMake. This matters
to us downstream in Swift, where we want to set environment variables
with the `env` command for every test.
Differential revision: https://reviews.llvm.org/D63679
llvm-svn: 364112
Summary:
ObjCLanguageRuntime was being pulled into LanguageRuntime because of
Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint,
we can extend the LanguageRuntime plugin interface so that LanguageRuntimes
can give us a BreakpointPrecondition for exceptions.
Differential Revision: https://reviews.llvm.org/D63181
llvm-svn: 364098
Introduce two common helpers to take care of splitting and recombining
YMM registers to/from XSAVE-like data. Since FreeBSD, Linux and NetBSD
all use XSAVE-like data structures but with potentially different field
layouts, the function takes two pointers -- to XMM register and to YMM
high bits, and copies the data from/to YMMReg type.
While at it, remove support for big endian. To mine and Pavel Labath's
combined knowledge, there is no such thing on x86. Furthermore,
assuming that the YMM register data would be swapped for big endian
seems to be a weird assumption.
Differential Revision: https://reviews.llvm.org/D63610
llvm-svn: 364042
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
Remove most of the abstraction over ptrace() register operations,
as it has little value and introduces more code than it saves.
Instead, leave a single ptrace() wrapper method and call it directly
from ReadRegisterSet() and WriteRegisterSet() with correct PT_* request
and buffer.
Remove the remaining direct ReadGPR() and WriteGPR() invocations
with ReadRegisterSet() and WriteRegisterSet().
Cleanup suggested by Pavel Labath in D63545.
Differential Revision: https://reviews.llvm.org/D63594
llvm-svn: 363923
That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (unused) decls.
llvm-svn: 363915
Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
external interface, from the internal representation. The external
interface can use llvm::Optional and similar goodies, while the data can
still be stored internally in a more compact representation.
I also document the purpose of the existing DIERef fields.
The main motivation for this change is a need to introduce an additional
field to the DIERef class, but I believe the change has its own merit.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63400
llvm-svn: 363910
Summary:
These fields are unused and have been since their inception, from what
I can tell.
Reviewers: compnerd, JDevlieghere, davide, labath
Subscribers: kubamracek, lldb-commits
Differential Revision: https://reviews.llvm.org/D63357
llvm-svn: 363881
Remove the checks for FPU presence, FXSAVE support and usage from
the code for x86_64. Those are always true for this architecture,
and in fact are hardcoded to true inside NetBSD kernel.
Differential Revision: https://reviews.llvm.org/D63554
llvm-svn: 363823
Summary:
Specify message levels in CMake. Prefer STATUS (stdout).
As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step.
This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default.
* I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations.
* Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know.
Patch by: Christoph Siedentop
Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz
Reviewed By: sgraenitz
Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits
Tags: #sanitizers, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D63370
llvm-svn: 363821
on some systems this test fails because the two methods it uses to
cross-reference the data don't match in the case of the vdso module. The
"read from /proc/%pid/maps" method returns "[vdso]", while the method
which reads it from the linker rendezvous structures returns
"linux-vdso.so.1". Neither of the two names match any actual file.
This restricts the test to only consider the libraries that we ourselves
have added to the test, minimizing the impact of system dependencies
that we cannot control.
llvm-svn: 363772
Summary:
This patch makes the DIERef class always valid by default constructor
and operator bool. This allows one to express the validity of a DIERef
in the type system. Places which are working with potentially-invalid
DIERefs have been updated to use Optional<DIERef> instead.
The constructor taking a DWARFFormValue was not needed, as all places
which were constructing a DIERef this way were immediately converting it
into a DWARFDIE or a user_id. This can be done without constructing an
intermediate DIERef.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63399
llvm-svn: 363767
Summary:
This is the fifth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Reading strings with ReadMemory is really slow when reading the path of the shared library. This is because we don't know the length of the path so use PATH_MAX (4096) and these strings are actually super close to the boundary of an unreadable page. So even though we use process_vm_readv it will usually fail because the read size spans to the unreadable page and we then default to read the string word by word with ptrace.
This new function is very similar to another ReadCStringFromMemory that already exists in lldb that makes sure it never reads cross page boundaries and checks if we already read the entire string by finding '\0'.
I was able to reduce the GetLoadedSharedLibraries call from 30ms to 4ms (or something of that order).
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62503
llvm-svn: 363750
Summary:
This is the fourth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Implement the `xfer:libraries-svr4` packet by adding a new function that generates the list and then in Handle_xfer I generate the XML for it. The XML is really simple so I'm just using string concatenation because I believe it's more readable than having to deal with a DOM api.
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, mgorny, srhines, krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62502
llvm-svn: 363707
Before this patch, reproducers weren't relocatable. The reproducer
contained hard coded paths in the VFS mapping, as well in the yaml file
listing the different input files for the command interpreter. This
patch changes that:
- Use relative paths for the DataCollector.
- Use an overlay prefix for the FileCollector.
Differential revision: https://reviews.llvm.org/D63467
llvm-svn: 363697
