We started passing the "all" target to make, which rendered the
"localall" trick in this Makefile inoperable.
I implement the strip step differently, and also reformat the Makefile.
llvm-svn: 323855
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
Strings which contain garbage data can trigger an exception in the XUnit
plugin at the UTF-8 decode step because the decode is strict. Use a lax
mode to avoid an exception.
See: https://ci.swift.org/job/oss-lldb-incremental-osx/780
llvm-svn: 323817
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
Summary:
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the error object was being cleared
only if logging was enabled.
Reviewers: davide, zturner, jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D42182
llvm-svn: 323753
The logic was incorrect because on windows, we need to look for
yaml2obj.EXE. I implement the search in terms of
distutils.spawn.find_executable, which should handle the platform
differences for us.
llvm-svn: 323744
Fix the Linux plugin lookup path to include appropriate libdir suffix
for the system. To accomplish this, store the value of
LLVM_LIBDIR_SUFFIX in lldb/Host/Config.h as LLDB_LIBDIR_SUFFIX,
and use this variable when defining the plugin path.
Differential Revision: https://reviews.llvm.org/D42317
llvm-svn: 323673
`num_args` is unsigned integer, declared as below:
```
uint32_t num_args = arg_enum->getChildCount();
```
Comparison with the signed `arg_idx` produces a warning when compiled with
-Wsign-compare flag, this patch addresses this simple issue without affecting
any functionality.
Reviewers: davide, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42620
llvm-svn: 323645
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).
Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).
Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.
Reviewers: eugene, krytarowski
Subscribers: mgorny, hintonda, lldb-commits
Differential Revision: https://reviews.llvm.org/D42488
llvm-svn: 323637
Summary:
Adds new utilities that make it easier to write test cases for lldb acting as a client over a gdb-remote connection.
- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy way to check client packets
- A MockGDBServer that, via MockGDBServerResponder, can be made to issue server responses that test client behavior.
- Utility functions for handling common data encoding/decoding
- Utility functions for creating dummy targets from YAML files
----
Split from the review at https://reviews.llvm.org/D42145, which was a new feature that necessitated the new testing capabilities.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: hintonda, davide, jingham, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42195
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 323636
Now the function returns `False`, and the caller can take the
appropriate action (in this case, for --executable, reporting
that the file doesn't exist).
llvm-svn: 323566
TestLibcxxListLoop - fails because the evil "define private public"
trick does not work with gmodules. The purpose of the test is not to
test debug info parsing so I just mark it as no_debug_info_testcase.
In the long term it may be interesting to write a mock std::list which
will allow us to test bad inputs to data formatters more easily.
TestGModules - seems to be a genuine bug. Filed pr36107 and xfailed.
llvm-svn: 323520
This test #include's stdio.h, which, on at least two bots results in a
module import of MacTypes.h (due to weird SDK layering issues), which
causes the test to fail to compile.
Just don't #include stdio.h, as it's not needed for the test.
llvm-svn: 323467
Stale global module caches cause problems for the bots. The modules
become invalid when clang headers are updated by version control, and
tests which use these modules fail to compile, e.g:
fatal error: file '.../__stddef_max_align_t.h' has been modified since the module file '/var/.../Darwin.pcm' was built
note: please rebuild precompiled header '/var/.../Darwin.pcm'
Eventually we should transition to having just a single module cache to speed
tests up. This patch should be just enough to fix the spurious bot failures due
to stale caches.
rdar://36479805, also related to llvm.org/PR36048
Differential Revision: https://reviews.llvm.org/D42277
llvm-svn: 323450
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line information about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D42434
llvm-svn: 323255
Summary: The GoParser is leaking memory in the tests due to not freeing allocated nodes when encountering some parsing errors. With this patch all GoParser tests are passing with enabled memory sanitizers/ubsan.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42409
llvm-svn: 323197
Summary:
It's possible to hit an unaligned memory read when reading `source_length` as the `data` array is only aligned with 2 bytes (it's actually a UTF16 array). This patch memcpy's `source_length` into a local variable to prevent this:
```
MinidumpTypes.cpp:49:23: runtime error: load of misaligned address 0x7f0f4792692a for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment
```
Reviewers: dvlahovski, zturner, davide
Reviewed By: davide
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D42348
llvm-svn: 323181
building method override tables for CXXMethodDecls in
DWARFASTParserClang::CompleteTypeFromDWARF.
C++ virtual method calls in LLDB expressions may fail if the override table for
the method being called is not correct as IRGen will produce references to the
wrong (or a missing) vtable entry.
This patch does not fix calls to virtual methods with covariant return types as
it mistakenly treats these as overloads, rather than overrides. This will be
addressed in a future patch.
Review: https://reviews.llvm.org/D41997
Partially fixes <rdar://problem/14205774>
llvm-svn: 323163
Summary: We can't use unique_ptr's here because we use those variables as `out` parameters to some functions. Discovered by the memory sanitizer.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42386
llvm-svn: 323138
Summary:
`m_last_tok` isn't initialized anywhere before it's used the first time (most likely in the `GoParser::Rule::error` method), which causes most of the GoParser tests to fail with sanitizers enabled with errors like this:
```
GoParser.cpp:52:21: runtime error: load of value <random value>, which is not a valid value for type 'GoLexer::TokenType'
UndefinedBehaviorSanitizer: undefined-behavior GoParser.cpp:52:21
```
Reviewers: ribrdb, davide, labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D42339
llvm-svn: 323119
Summary:
This patch implements the ABI Plugin for PPC64le. It was based on the
ABI for PPC64. It also enables LLDB to evaluate expressions using JIT.
Reviewers: labath, clayborg, jhibbits, davide
Reviewed By: labath, clayborg, jhibbits, davide
Subscribers: davide, JDevlieghere, chmeee, emaste, jhibbits, hfinkel, lldb-commits, nemanjai, luporl, lbianc, mgorny, anajuliapc, kbarton
Differential Revision: https://reviews.llvm.org/D41702
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>
llvm-svn: 323100
Summary:
We copy the local variable `Resolved` into `Storage` to keep it around. However, we then still let the `SearchDir` ref point to `Resolved` which then is used to access the already freed memory later on. With this patch we point to `Storage` which doesn't get deleted after the current scope exits.
Discovered by memory sanitizer in the CompletionTest.DirCompletionUsername test.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42346
llvm-svn: 323082
Summary: float can't represent the given value in the literal, so we get this UB error: `runtime error: 1.23457e+48 is outside the range of representable values of type 'float'`. The test seems to not rely on this specific value, so let's just choose a smaller one that can be represented.
Reviewers: uweigand
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42338
llvm-svn: 323081
Summary: We never delete the created instances, so those test fail with the memory sanitizer.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: aemerson, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D42336
llvm-svn: 323076
Clean up needless+missing #include "DWARFCompileUnit.h" for split of
DWARFCompileUnit to DWARFUnit as discussed in D40466.
Differential revision: https://reviews.llvm.org/D42355
llvm-svn: 323069
Summary:
This patch adds missing includes to the LLDB headers inside `include/` as a first step of building LLDB's source with C++ modules. It also fixes this single `stds::` typo.
Some quick map why some non-obvious includes were necessary:
* lldb/lldb-defines.h for LLDB_INVALID_ADDRESS
* lldb/lldb-types.h for addr_t
* lldb/lldb-defines.h for DISALLOW_COPY_AND_ASSIG
* lldb/DataFormatters/TypeSynthetic.h for SyntheticChildrenFrontEnd
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D42340
llvm-svn: 323064
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits, davide, asmith
Reviewed By: zturner, asmith
Subscribers: llvm-commits, davide
Differential Revision: https://reviews.llvm.org/D41427
llvm-svn: 322995
Summary:
These were used by Host::LaunchProcess to "resolve" the executable it
was about to launch. The only parts of Platform::ResolveExecutable, which
seem to be relevant here are the FileSpec::ResolvePath and
ResolveExecutableLocation calls.
The rest (most) of that function deals with selecting an architecture
out of a fat binary and making sure we are able to create a Module with that
slice. These are reasonable actions when selecting a binary to debug,
but not for a generic process launching framework (it's technically even
wrong because we should be able to launch a binary with execute
permissions only, but trying to parse such file will obviously fail).
I remove the platform call by inlining the relevant FileSpec calls and
ignoring the rest of the Platform::ResolveExecutable code. The
architecture found by the slice-searching code is being ignored already
anyway, as we use the one specified in the LaunchInfo, so the only
effect of this should be a different error message in case the
executable does not contain the requested architecture -- before we
would get an error message from the Platform class, but now we will get
an error from the actual posix_spawn syscall (this is only relevant on
mac, as it's the only target supporting fat binaries).
Launching targets for debugging should not be affected as here the
executable is pre-resolved at the point when the Target is created.
Reviewers: jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D41902
llvm-svn: 322935
Refactor in r322653 broke the logging test on windows because MSVC uses
a fully qualified name as the value of __FUNCTION__, which is not what
we were expecting. I'm changing the code to use the more portable
__func__, which behaves the same as on clang/gcc.
The standard still says that the value of __func__ is implementation
defined, so if we run into problems with this test again we may just
need to drop it.
llvm-svn: 322834
On Darwin, if a test machine isn't set up for code-signing (see
docs/code-signing.txt), running check-lldb should use the system
debugserver instead of the unsigned one built in-tree. This makes it
possible to run lldb's test suite without having code-signing set up,
which is really convenient.
Differential Revision: https://reviews.llvm.org/D42215
llvm-svn: 322803
Due to an unfortunate difference between the open source test harness
and our internal harness, applying two @skip... decorators to this test
works in the internal build but not in the open source build.
I've tried another approach to skipping this test and tested it out with
the open source harness. Hopefully this sticks!
rdar://36417163
llvm-svn: 322756
This test frequently times out on our bots. While we're investigating
the issue, mark the test as skipped so the builds aren't impacted as
much.
rdar://36417163
llvm-svn: 322728
Summary:
LLDB's DumpDataExtractor was not prepared to handle PowerPC's long double type: PPCDoubleDouble.
As it is somewhat special, treating it as other regular float types resulted in getting wrong information about it.
In this particular case, llvm::APFloat::getSizeInBits(PPCDoubleDouble) was returning 0.
This caused the TestSetValues.py test to fail, because lldb would abort on an assertion failure on APInt(), because of the invalid size.
Since in the PPC case the value of item_byte_size was correct and the
getSizeInBits call was only added to support x87DoubleExtended
semantics, this restricts the usage of getSizeInBits to the x87
semantics.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: llvm-commits, anajuliapc, alexandreyy, lbianc, lldb-commits
Differential Revision: https://reviews.llvm.org/D42083
Author: Leandro Lupori <leandro.lupori@gmail.com>
llvm-svn: 322666
In D40616 I (mistakenly) assumed that logging an llvm::Error would clear
it. This of course is only true if logging is actually enabled.
This fixes the assertion by manually clearing the error, but it raises
the point of whether we need a special error-clearing logging primitive.
llvm-svn: 322664
This removes boilerplate for setting up a log channel and capturing the
output from some of the tests. I do this by moving the setup code into a
test fixture and adding a logAndTakeOutput utility function to log some
string and then retrieve it from the log.
I also use some googlemock goodies to simplify a couple of assertions.
llvm-svn: 322653
The comment seems to indicate that this function would return the "bin"
directory on linux. I've verified that this is not the case, so I'm
updating the comment to match.
llvm-svn: 322472
Summary:
This commit is a combination of the following changes:
- Cache PDB's global scope (executable) in SymbolFilePDB
- Change naming of `cu` to `compiland` which is PDB specific
- Change ParseCompileUnitForSymIndex to ParseCompileUnitForUID.
Prefer using a common name `UID` instead of PDB's `System Index`
Adding one more argument `index` to this method, which is used to
specify the index of the compile unit in a cached compile unit array
- Add GetPDBCompilandByUID method to simply code
- Fix a bug in getting the source file name for a PDB compiland.
For some reason, PDBSymbolCompiland::getSourceFileName() could
return an empty name, so if that is true, we have to walk through all
source files of this compiland and determine the right source file
used to generate this compiland based on language indicated.
The previous implementation called PDBSession::findOneSourceFile
method to get its name for the compiland. This is not accurate since
the `one source file` found could be a header other than source file.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41428
llvm-svn: 322433
of a dSYM per-uuid plist that may be present (dsymutil does not
create this plist, it is only added after the fact by additional
tools) -- either the DBGBuildSourcePath + DBGSourcePath pair of
k-v entries which give us the build-time and debug-time remapping,
or the newer DBGSourcePathRemapping dictionary which may give us
multiple remappings.
I'm changing the order that we process these & add them to the
list of source remappings. If the DBGSourcePathRemapping dict
is present, it should be the first entries we will try.
<rdar://problem/36481989>
llvm-svn: 322418
RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't also clearing the locations from
the address->location map, which confused us when we went to update
breakpoint locations.
I also made Breakpoint::ModulesChanged check the Location's Section
to make sure it hadn't been deleted. This shouldn't strictly be necessary,
but if the DynamicLoaderPlugin doesn't do it's job right (I'm looking at
you new Darwin DynamicLoader...) then it can end up leaving stale locations
on rerun. It doesn't hurt to clean them up here as a backstop.
<rdar://problem/36134350>
llvm-svn: 322348
This test stresses expression evaluation support for template functions.
Currently the support is rudimentary, and running this test causes assertion
failures in clang. This test cannot be XFAIL'ed because the test harness
treats assertion failures as unexpected events. For now, the test must be
skipped.
llvm-svn: 322340
been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProcessInfo), and the target.xml
includes a <architecture> tag specifying x86_64, set the architecture
appropriately.
I'm not sure what we can expect to see in the <architecture> tag, so
I'm only doing this for x86_64 right now where I've seen "i386:x86_64"
used. I've seen a target.xml from a jtag board that sends just "arm"
because it doesn't know more specifically what type of board it is
connected to...
<rdar://problem/29908970>
llvm-svn: 322339
Summary:
Actually, fix two issues:
# remove repeat creation of reg_info, use m_reg_info_ap for createMCAsmInfo instead;
# remove possibility to dereference nullptr during createMCAsmInfo invocation, that could lead to undefined behavior.
Placed checking of a component right after its creation to simplify the code and avoid same issues later.
Reviewers: zturner, clayborg, jingham, jasonmolenda, labath
Reviewed By: clayborg, labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D41584
llvm-svn: 322270
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
This is r322209, but with fixed VDSO loading fixed.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322251
from being listed as a part of the desktop or
desktop/desktop_no_xpc Targets - they should not be
a part of any target. Having them listed as a part of
desktop target results in them being added to the
Copy Files build phase for desktop and I'm guessing
they'd end up in the manpage directory or something.
llvm-svn: 322237
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322209
Summary:
Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this causes lldb to get out of sync with future commands because it continues reading O packets from the first command as response to subsequent commands.
This patch handles any O packets during an qRcmd, treating the first non-O packet as the true response.
Preliminary discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D41745
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 322190
the previous fix did not work because of different const qualifications
on the envp pointer.
This should resolve that (and remove a couple of const_casts in the
process).
llvm-svn: 322187
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Summary:
This used to be important when all tests were run in a single process,
but that has no longer been the case for a while. Furthermore, this hook fails
to build on new mac versions for several people, and it's not clear
whether fixing it is worth the effort.
Reviewers: jingham, clayborg, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41871
llvm-svn: 322167
(built with Xcode) from 10.9 to 10.11. It also enables the use of
libcompression in debugserver by default (these API are only present
in macOS 10.11 and newer -- 10.11 was released c. Sep 2015).
I don't know if we have people / bots building lldb on older mac
releases; if this turns out to be a problem I will revert the change.
There are some parts of lldb (e.g. debugserer's ability to report
the OS version #) that only work with 10.10 and this changes the
behavior of lldb (whether the older or newer dyld interfaces are
used) so there is some importance to updating the min required
version.
llvm-svn: 322128
The HAVE_LIBZ variable is not exported by LLVM, and therefore is not
available in stand-alone builds of other tools. Use LLVM_ENABLE_ZLIB
which is the name under which the effective value is exported.
Additional, use llvm_canonicalize_cmake_booleans() to make sure that
a correct (Python-safe) boolean value is passed down to lit.
Differential Revision: https://reviews.llvm.org/D41725
llvm-svn: 322081
Use full PATH when looking up test tools rather than just llvm tools
directory. r320813 has added a lookup for 'lldb-test' which is part
of LLDB tools rather than LLVM, and therefore is not present
in llvm_tools_dir before LLDB is installed.
While technically we could introduce separate per-directory lookup
logic, there is no real reason not to use the PATH formed earlier here,
and this is what other tools are doing.
Differential Revision: https://reviews.llvm.org/D41726
llvm-svn: 321932
This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle
that was particularly noticable when debugging LLVM itself.
Debugging without clang modules and DWO handling should be unaffected by this patch.
<rdar://problem/32436209>
llvm-svn: 321802
Summary: D41086 fixed an exception in FindTypes()/FindTypesByRegex() and caused two lldb unit test to fail. This change updates the unit tests to pass again.
Reviewers: zturner, lldb-commits, labath, clayborg, asmith
Reviewed By: asmith
Differential Revision: https://reviews.llvm.org/D41550
llvm-svn: 321511
Summary:
Make sure we propagate environment when starting debugserver with a pre-loaded
inferior. AFAIK, RNBRunLoopLaunchInferior is only called in pre-loaded inferior
scenario, so we can just pick up the debugserver environment instead of trying
to construct an envp from the (empty) context.
This makes debugserver pass an test added for an equivalent lldb-server fix.
Reviewers: jasonmolenda, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41352
llvm-svn: 321355
The test works fine on linux, and I believe other targets should not
have an issue with as well. If they do, we can start blacklisting
instead of whitelisting.
The idea of using "-1" as the value of the pointer on non-apple targets
backfired, as it fails the "address != LLDB_INVALID_ADDRESS" test (-1 is
the value of LLDB_INVALID_ADDRESS). However, it should be safe to use
0x100 for other targets as well. The first page of memory is generally
kept unreadable to catch null pointer dereferences.
llvm-svn: 321353
Summary:
It was possible when searching for a symbol by regex in a pdb that an invalid regex would cause an exception on Windows. This updates the code to avoid throwing an exception.
When fixing the exception it was decided there is no reason to search for a symbol in a pdb by regex. To support this, SymbolFilePDB::FindTypes() now only searches for types by name and no longer calls FindTypesByRegEx().
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: clayborg
Differential Revision: https://reviews.llvm.org/D41086
llvm-svn: 321344
an empty Python string object when it reads a 0-length
string out of memory (and a successful SBError object).
<rdar://problem/26186692>
llvm-svn: 321338
Two tests were failing because the debugger was picking up multiply
defined internal symbols from the system libraries. This is a bug, as
there should be no ambiguity because the tests are defining variables
with should shadow these symbols, but lldb is not smart enough to figure
that out.
I work around the issue by renaming the variables in these tests, and in
exchange I create a self-contained test which reproduces the issue
without depending on the system libraries.
This increases the predictability of our test suite.
llvm-svn: 321271
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
The recent UUID cleanups exposed a bug in the parsing code for the
jModulesInfo response, which was passing wrong value for the second
argument to UUID::SetFromStringRef (it passed the length of the string,
whereas the correct value should be the number of decoded bytes we
expect to receive).
This was not picked up by tests, because they test with 16-byte uuids,
for which the function happens to do the right thing even if the length
does not match (if the length does not match, the function does not
update m_num_uuid_bytes member, but that member is already 16 to begin
with).
I fix that and add a test with 20-byte uuid to catch if this regresses.
I have also added more safeguards into the parsing code to fail if we
cannot parse the entire uuid field we recieve. While testing the latter
part, I noticed that the "negative" jModulesInfo tests were succeeding
because we were sending malformed json (and not because the json
contents was invalid), so I make those tests a bit more robuts as well.
llvm-svn: 320985
Summary:
We were failing to propagate the environment when lldb-server was
started with a pre-loaded process
(e.g.: lldb-server gdbserver -- inferior --inferior_args)
This patch makes sure the environment is propagated. Instead of adding a
new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to
complement SetLaunchArgs and SetLaunchFlags, I replace these with a
more generic SetLaunchInfo, which can be used to set any launch-related
property.
The accompanying test also verifies that the server correctly terminates
the connection after sending the exit packet (specifically, that it does
not send the exit packet twice).
Reviewers: clayborg, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41070
llvm-svn: 320984
Summary:
The x86 FPR struct was defined as a struct containing a union between
two members: XSAVE and FXSAVE. This patch makes FPR a union directly to
remove one layer of indirection when trying to access the members.
The initial layout of these two structs is identical, which is
recognised by the fact that XSAVE has FXSAVE as its first member, so we
also considered removing one more layer and leave FPR identical to XSAVE
struct, but stopped short of doing that, as the FPR may be used to store
different layouts in the future (e.g., ones generated by the FSAVE
instruction).
Reviewers: clayborg, krytarowski
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D41245
llvm-svn: 320966
Summary:
lldb-server was sending the "exit" packet (W??) twice. This happened
because it was handling both the pre-exit (PTRACE_EVENT_EXIT) and
post-exit (WIFEXITED) as exit events. We had some code which was trying
to detect when we've already sent the exit packet, but this stopped
working quite a while ago.
This never really caused any problems in practice because the client
automatically closes the connection after receiving the first packet, so
the only effect of this was some warning messages about extra packets
from the lldb-server test suite, which were ignored because they didn't
fail the test.
The new test suite will be stricter about this, so I fix this issue
ignoring the first event. I think this is the correct behavior, as the
inferior is not really dead at that point, so it's premature to send the
exit packet.
There isn't an actual test yet which would verify the exit behavior, but
in my next patch I will add a test which will also test this
functionality.
Reviewers: eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41069
llvm-svn: 320961
"Default" is a valid QoS for a thread on older versions of macOS,
like the one installed in the bot.
Thanks to Jason Molenda for helping me figuring out the problem.
<rdar://problem/28346273>
llvm-svn: 320883
Summary:
This makes StopReply class abstract, so that we can represent different
types of stop replies such as StopReplyStop and StopReplyExit (there
should also be a StopReplySignal, but I don't need that right now so I
haven't implemented it yet).
This prepares the ground for a new test I'm writing.
Reviewers: eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41067
llvm-svn: 320820
Summary:
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is only available if
llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
Summary:
Adding a new test would require one to duplicate a significant part of
the existing test that we have. This attempts to reduce that by moving
some part of that code to the test fixture. The StandardStartupTest
fixture automatically starts up the server and connects it to the
client. I also add a more low-level TestBase fixture, which allows one
to start up the client and server in a custom way (I am going to need
this for the test I am writing).
Reviewers: eugene, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41066
llvm-svn: 320809
Clang recently switched to C++14 (with GNU extensions) as the default
dialect, but LLDB didn't catch up. This causes failures as LLDB still
evaluates ObjectiveC expressions as Objective C++ using C++98 as standard.
There are things not available in C++98, including, e.g. nullptr.
In some cases Objective-C `nil` is defined as `nullptr` so this causes
an evaluation failure. Switch the default to overcome this issue
(actually, currently lldb evaluates both C++11 and C++14 as C++11,
but that seems a larger change and definitely could be re-evaluated
in the future).
No test as this is currently failing on the LLDB bots after the clang
switch (so, de facto, there's a test already for it).
This is a recommit, with a thinko fixed (the code was previously
placed incorrectly).
<rdar://problem/36011995>
llvm-svn: 320778
Clang recently switched to C++14 (with GNU extensions) as the default
dialect, but LLDB didn't catch up. This causes failures as LLDB still
evaluates ObjectiveC expressions as Objective C++ using C++98 as standard.
There are things not available in C++98, including, e.g. nullptr.
In some cases Objective-C `nil` is defined as `nullptr` so this causes
an evaluation failure. Switch the default to overcome this issue
(actually, currently lldb evaluates both C++11 and C++14 as C++11,
but that seems a larger change and definitely could be re-evaluated
in the future).
No test as this is currently failing on the LLDB bots after the clang
switch (so, de facto, there's a test already for it).
<rdar://problem/36011995>
llvm-svn: 320761
Summary:
These two functions were calling each other, while handling different
branches of the if(IsInMemory()). This had a reason at some point in the
past, but right now it's just confusing.
I resolve this by removing the MemoryMapSectionData function and
inlining the !IsInMemory branch into ReadSectionData. There isn't
anything mmap-related in this function anyway, as the decision whether
to mmap is handled at a higher level.
This is a preparatory step to make ObjectFileELF be able to decompress
compressed sections (I want to make sure that all calls reading section
data are routed through a single piece of code).
Reviewers: clayborg
Subscribers: emaste, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41169
llvm-svn: 320705
A similar error message is printed again in lldb-gdbserver.cpp, so the
user will see the message twice. Also, this is generic library code, we
shouldn't really be using stderr here.
llvm-svn: 320704
This is needed to ensure that the distribution and install-distribution
targets work properly.
Differential Revision: https://reviews.llvm.org/D41144
llvm-svn: 320537
I tested on x86-64 and Jason on embedded architectures.
This cleans up another couple of reported unexpected successes.
<rdar://problem/28623427>
llvm-svn: 320452
After discussing this with Jim and Jason, I think my commit was
actually sweeping the issue under the carpet rather than fixing it.
I'll take a closer look between tonight and tomorrow.
llvm-svn: 320447
Some tests are failing on macOS when building with the in-tree
clang, and this is because they're conditional on the version released.
Apple releases using a different versioning number, but as these are
conditional on clang < 7, they fail for clang ToT (which is 6.0).
As a general solution, we actually need either a mapping between
Apple internal release version and public ones.
That said, I discussed this with Fred , and Apple Clang 6.0 seems
to be old enough that we can remove this altogether (which means I
can delay implementing the general purpose solution for a bit).
Differential Revision: https://reviews.llvm.org/D41101
llvm-svn: 320444
This adds the install-*-stripped targets to LLDB, which are required for
the install-distribution-stripped option. We also need to create some
install-*-stripped targets manually, which are modeled after their
corresponding install-* targets.
Differential Revision: https://reviews.llvm.org/D41099
llvm-svn: 320443
This is the first of a series of commits aiming to improve
overall LLDB's hygiene. Feel free to shout at me in case
I break something.
<rdar://problem/30915340>
llvm-svn: 320425
Host::GetEnvironment returns a StringList, but the interface for
launching a process takes Args. The fact that we use two classes for
representing an environment is not ideal, but for now we should at least
have an easy way to convert between the two.
llvm-svn: 320366
Summary:
For ptys (at least on Linux), the end-of-file (closing of the slave FD)
is signalled by the POLLHUP flag. We were ignoring this flag, which
meant that when this happened, we would spin in a loop, continuously
calling poll(2) and not making any progress.
This makes sure we treat POLLHUP as a read event (reading will return
0), and we call the registered callback when it happens. This is the
behavior our clients expect (and is consistent with how select(2)
works).
Reviewers: eugene, beanz
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41008
llvm-svn: 320345
They cause an ubsan error when ran through the testsuite (store
to misaligned address is UB). This commit kills two birds with
one stone, as we also remove some code while fixing it.
<rdar://problem/35941757>
llvm-svn: 320335
computer. When doing kernel debugging, lldb scrapes around a few
well-known locations to find kexts and kernels. It builds up two
lists - kexts and kernels with dSYM, and kexts and kernels without dSYMs.
After both lists have failed to provide a file, then we'll call out
to things like the DebugSymbols framework to find a kext/kernel.
This meant that when you had a kext/kernel on the local computer that
did not have debug information, lldb wouldn't consult DebugSymbols etc
once it'd locked on to one of these no-debug-info binaries on the local
computer.
Reorder this so we give DebugSymbols etc a shot at finding a debug-info
file before we use any of the no-debug-info binaries that were found on
the system.
<rdar://problem/34434440>
llvm-svn: 320241
most common cases where the Xcode.app bundle puts lldb -
either as a default part of the bundle, or in a toolchain
subdirectory, so the platform subclasses can find files
relative to this directory.
Dropped support for handling the case where the lldb
framework was in /Library/PrivateFrameworks. I think
this was intended to handle the case where lldb is installed
in / (outside the Xcode.app bundle) - but in that case, we
can look in the raw directory file paths to find anything.
<rdar://problem/35285622>
llvm-svn: 320240
Fix alignment UB in some Mach exception-handling logic.
This lets us build lldb and debugserver with UBSan in trapping mode, and
get further along in the testing process before a trap is encountered.
rdar://35923991
llvm-svn: 320127
This part of lldb make use of anonymous structs and unions. The usage is
idiomatic and doesn't deserve a warning. Logic in the NSDictionary and NSSet
plugins use anonymous structs in a manner consistent with the relevant Apple
frameworks.
Differential Revision: https://reviews.llvm.org/D40757
llvm-svn: 320071
They're hidden, so all they cause is a linker warning.
ld: warning: cannot export hidden symbol
lldb::SBBreakpointNameImpl::operator==(lldb::SBBreakpointNameImpl const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBreakpointName.cpp.o
llvm-svn: 320066
Summary:
Variable::GetValuesForVariableExpressionPath was passing an
uninitialised value for the final_task_on_target argument. On my
compiler/optimization level combo, the final_task_on_target happened to
contain "dereference" in some circumstances, which produced hilarious
results. The same is true for other arguments to the
GetValueForExpressionPath call.
The correct behavior here seems to be to just omit the arguments
altogether and let the default behavior take place.
Reviewers: jingham
Subscribers: mehdi_amini, lldb-commits
Differential Revision: https://reviews.llvm.org/D40557
llvm-svn: 320021
This is a follow-up to r319840. I guess none of the systems I'd tested
on before had LLDB_SYSTEM_LIBS set, which is why I didn't see any local
errors, but I'm surprised none of the bots caught it either.
llvm-svn: 319953
A few methods in RegisterContext classes accept const objects which are
cast to a non-const thread_state_t. Drop const-ness more explicitly
where we mean to do so. This fixes a slew of warnings.
Differential Revision: https://reviews.llvm.org/D40821
llvm-svn: 319939
Null-checking functions which aren't marked weak_import is a no-op
(the compiler rewrites the check to 'true'), regardless of whether a
library providing its definition is weak-linked. If the deployment
target is greater than the minimum requirement, the availability markup
on APIs does not lower to weak_import.
Remove no-op null checks to clean up the code and silence warnings.
Differential Revision: https://reviews.llvm.org/D40812
llvm-svn: 319936
Summary: There are "FIXME"s in include/llvm/IR/DataLayout.h to remove the default arguments.
Reviewers: zturner, clayborg
Reviewed By: zturner
Subscribers: bjope
Differential Revision: https://reviews.llvm.org/D40064
llvm-svn: 319869
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
I was warning about the fact that this will abort
further stop hooks, but didn't check that there WAS
a further stop hook. Also the warning was missing a
newline.
llvm-svn: 319730
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail because of
that depends on the linux distro and c++ library version.
A bunch of tests were already setting these flags manually, but here
instead I take a whole sale approach and enable this flag for all tests.
Any test which does not want to have this flag (right now we have one
such test) can turn it off explicitly via
CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS)
This fixes a bunch of data formatter tests on red-hat.
Reviewers: davide, jankratochvil
Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D40717
llvm-svn: 319653
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the process even when lldb isn't used. I have a bunch
of reports of this SignalHandler blowing out the stack,
which renders crash reports for the crash useless.
And in any case libraries really shouldn't be installing
signal handlers.
I only turned this off for APPLE platforms, I'll let
the maintainers of other platforms decide what policy
they want to have w.r.t. this.
llvm-svn: 319598
struct iovec is used as an interface to system (posix) api's. As such,
we shouldn't be using it in os-independent code, and we shouldn't be
defining our own iovec replacements.
Fortunately, its usage was not very widespread, so the removal was very
easy -- I simply moved a couple declarations into os-specific code.
llvm-svn: 319536
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.
Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.
Run the tool as `lldb-test module-sections <path-to-object>`.
Feel free to add testing related stuff to your heart's content after
this goes in. Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.
Differential Revision: https://reviews.llvm.org/D40636
llvm-svn: 319504
but still listed in the kernel's kext table with the kernel
binary UUID. This resulted in the kernel text section being
loaded at the kext address and problems ensuing. Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.
<rdar://problem/35757689>
llvm-svn: 319500
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std:🧵:hardware_concurrency may return 0,
handle this case correctly.
Differential revision: https://reviews.llvm.org/D40587
Test plan: make check-all
llvm-svn: 319492
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificially throwing off the test.
llvm-svn: 319472
Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.
Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40615
llvm-svn: 319414
It has no functionality effect.
I was concerned about the worse performance of DWARFDebugInfo::Parse this way
of allocating+destroying a CU for each iteration but I see it is now used only
by DWARFDebugInfo::Dump so that is no longer a problem.
Differential revision: https://reviews.llvm.org/D40212
llvm-svn: 319359
Summary: This remove a small amount of duplicated code.
Reviewers: clayborg, zturner, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40536
llvm-svn: 319191
In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register context.
However, existing register contexts were still using the old method.
This converts the remaining register contexts to use this approach.
While doing that, I've had to modify the approach a bit:
- the general purpose register set is still kept as a separate field,
because this one is always present, and it's parsing is somewhat
different than that of other register sets.
- since the same register sets have different IDs on different operating
systems, but we use the same register context class to represent
different register sets, I've needed to add a layer of indirection to
translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more
generic terms (e.g. floating point register set).
While slightly more complicated, this setup allows for better separation
of concerns. The parsing code in ProcessElfCore can focus on parsing
OS-specific core file notes, and can completely ignore
architecture-specific register sets (by just storing any unrecognised
notes in a map). These notes will then be passed on to the
architecture-specific register context, which can just deal with
architecture specifics, because the OS-specific note types are hidden in
a register set description map.
This way, adding an register set, which is already supported on other
OSes, to a new OS, should in most cases be as simple as adding a new
entry into the register set description map.
Differential Revision: https://reviews.llvm.org/D40133
llvm-svn: 319162
Summary:
New linux kernels (on systems that support the XSAVES instruction) will
not update the inferior registers unless the corresponding flag in the
XSAVE header is set. Normally this flag will be set in our image of the
XSAVE area (since we obtained it from the kernel), but if the inferior
has never used the corresponding register set, the respective flag can
be clear.
This fixes the issue by making sure we explicitly set the flags
corresponding to the registers we modify. I don't try to precisely match
the flags to set on each write, as the rules could get quite complicated
-- I use a simpler over-approximation instead.
This was already caught by test_fp_register_write, but that was only
because the code that ran before main() did not use some of the register
sets. Since nothing in this test relies on being stopped in main(), I
modify the test to stop at the entry point instead, so we can be sure
the inferior did not have a chance to access these registers.
Reviewers: clayborg, valentinagiusti
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40434
llvm-svn: 319161
Summary:
This method doesn't modify anything in the object it's called on so we
can mark it const to make it usable in a const context.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40517
llvm-svn: 319095
This was a temporary thing, until llvm has proper support for formatting
time. That time has come, so we can remove the relevant code. There
should be no change in the format of the time.
llvm-svn: 319048
New android ndk linker started adding more flags to the produced
binaries, which causes older dynamic linkers display warnings to stderr
about unsupported flags. This interferes with our stderr tests.
Extend the hasChattyStderr function to catch these targets as well.
llvm-svn: 319028
Summary:
We've had a single function responsible for splitting a core segment
into notes, and parsing the notes themselves, bearing in mind variations
between 4 supported OS types. This commit splits that code into 5
pieces:
- (os-independent) code for splitting a segment into individual notes
- per-os function for parsing the notes into thread information
Reviewers: clayborg, krytarowski, emaste, alexandreyy, kettenis
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40311
llvm-svn: 318903
DWO/DWP should not be indexed directly.
Instead, the corresponding base file should be used.
This diff adds an assert to DWARFCompileUnit::Index
and adjusts the methods
SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE,
SymbolFileDWARF::GetObjCMethodDIEOffsets accordingly.
Differential revision: https://reviews.llvm.org/D39825
llvm-svn: 318554
so it has the same padding as the kernel's definition
which is written in terms of uint128_t. Original patch
by Ryan Mansfield.
<rdar://problem/35468499>
llvm-svn: 318357
break. The alignas(__uint128_t) is not recognized with MSVC
it looks like. Zachary, is there a similar type on windows?
I suppose I can go with alignas(16) here but I'd prefer to
specify the type alignment that I want & let the ABI dictate
how much padding is required.
llvm-svn: 318262
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Summary:
In D39387, I was quick to jump to conclusion that ArchSpec has no
external dependencies. It turns there still was one call to
HostInfo::GetArchitecture left -- for implementing the "systemArch32"
architecture and friends.
Since GetAugmentedArchSpec is the place we handle these "incomplete"
triples that don't specify os or vendor and "systemArch" looks very much
like an incomplete triple, I move its handling there.
After this ArchSpec *really* does not have external dependencies, and
I'll move it to the Utility module as a follow-up.
Reviewers: zturner, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39896
llvm-svn: 318046
Summary:
Despite it's name, GetTemplateArgument was only really working for Type
template arguments. This adds the ability to retrieve integral arguments
as well (which I've needed for the std::bitset data formatter).
I've done this by splitting the function into three pieces. The idea is
that one first calls GetTemplateArgumentKind (first function) to
determine the what kind of a parameter this is. Based on that, one can
then use specialized functions to retrieve the correct value. Currently,
I only implement two of these: GetTypeTemplateArgument and
GetIntegralTemplateArgument.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39844
llvm-svn: 318040
This commit really did not introduce any functional changes (for most
people) but it turns out it's not for the reason we thought it was.
The reason wasn't that Orc is a perfect drop-in replacement for MCJIT,
but it was because we were never using Orc in the first place, as it was
not initialized.
Orc's initialization relies on a global constructor in the LLVMOrcJIT.a.
Since this archive does not expose any symbols referenced from other
object files, it does not get linked into liblldb when linking against
llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On
build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so
the global constructor does end up firing.
The result of using Orc jit is pr34194, where lldb fails to evaluate
even very simple expressions. This bug can be reproduced in
non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into
liblldb, for example by #including
llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and
adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The
bug reproduces (at least) on linux and osx.
The root cause of the bug seems to be related to relocation processing.
It seems Orc processes relocations earlier than the system it is
replacing. This means the relocation processing happens before we have
had a chance to remap section load addresses to reflect their address in
the target process memory, so they end up pointing to locations in the
lldb's address space instead.
I am not sure whether this is a bug in Orc jit, or in how we are using
it from lldb, but in any case it is preventing us from using Orc right
now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear
that we are in fact *not* using Orc, and we never really were.
This reverts commit r279327.
llvm-svn: 318039
FindCompleteObjCDefinitionType is not used anywhere and there is no implementation of it, only a declaration.
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D39884
llvm-svn: 317919
Summary:
This commit removes the concrete_frame_idx member from
NativeRegisterContext and related functions, which was always set to
zero and never used.
I also change the native thread class to store a NativeRegisterContext
as a unique_ptr (documenting the ownership) and make sure it is always
initialized (most of the code was already blindly dereferencing the
register context pointer, assuming it would always be present -- this
makes its treatment consistent).
Reviewers: eugene, clayborg, krytarowski
Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D39837
llvm-svn: 317881
Summary:
These tests used to log the error message and return plain bool mainly
because at the time they we written, we did not have a nice way to
assert on llvm::Error values. That is no longer true, so replace this
pattern with a more idiomatic approach.
As a part of this patch, I also move the formatting of
GDBRemoteCommunication::PacketResult values out of the test code, as
that can be useful elsewhere.
Reviewers: zturner, eugene
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D39790
llvm-svn: 317795
Summary:
These functions used to return bool to signify whether they were able to
retrieve the data. This is redundant because the ArchSpec and ByteOrder
already have their own "invalid" states, *and* because both of the
current implementations (linux, netbsd) can always provide a valid
result.
This allows us to simplify bits of the code handling these values.
Reviewers: eugene, krytarowski
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39733
llvm-svn: 317779
r317561 exposed an interesting bug (pr35228) in handling of simultaneous
watchpoint hits. Disabling the test until we can get that fixed.
llvm-svn: 317683
The thread name was not followed by a space, which meant it was glued to
the log message. I also align the name as we do that with other log
fields. I align it to 16 chars instead of llvm::max_thread_name(), as
that can be 64 on darwin, which is rather long. If anybody feels
differently about that, we can change it.
llvm-svn: 317679
Summary:
This test was failing in various configurations on linux in a fairly
unpredictible way. The success depended on whether the c++ abi library
was linked in statically or not and how well was the linker able to
strip parts of it. This introduces additional code to the "dummmy" test
executable, which ensures that all parts of the library needed to
evaluate the expressions are always present.
Reviewers: clayborg
Subscribers: srhines, tatyana-krasnukha, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D39727
llvm-svn: 317678
Summary:
A couple of members of these data structures have been renamed in recent
months. This makes sure they still work with the latest libc++ version.
Reviewers: jingham, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39602
llvm-svn: 317624
Summary:
The test incremented an atomic varible to trigger the watchpoint event.
On arm64 this compiled to a ldaxr/stlxr loop, with the watchpoint being
triggered in the middle of the loop. Hitting the watchpoint resets the
exclusive monitor, and forces the process to loop one more time, hitting
the watchpoint again, etc.
While it would be nice if the debugger was able to resume from this
situation, this is not trivial, and is not what this test is about.
Therefore, I propose to change this to a simple store to a normal
variable (which should still trip the watchpoint everywhere, but without
atomic loops) and file a bug to investigate the possibilities of
handling the watchpoints in atomic loops in a more reasonable way.
Reviewers: clayborg
Subscribers: aemerson, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D39680
llvm-svn: 317561
Summary: These fail because `-fPIC` is not supported on Windows.
Reviewers: zturner, jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39692
llvm-svn: 317529
Summary:
This is required when using the in-tree clang for building tests,
because -fuse-ld=lld is used by default.
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D39689
llvm-svn: 317501
Summary:
Posix core files sometime don't contain enough information to correctly
detect the OS. If that is the case we should use the OS from the target
instead as it will contain usable information in more cases and if the
target and the core contain different OS-es then we are already in a
pretty bad state so moving from an unknown OS to a known (but possibly
incorrect) OS will do no harm.
We already had similar code in place for MIPS. This change tries to make
it more generic by using ArchSpec::MergeFrom and extends it to all
architectures but some MIPS specific issue prevent us from getting rid
of special casing MIPS.
Reviewers: clayborg, nitesh.jain
Subscribers: aemerson, sdardis, arichardson, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D36046
llvm-svn: 317411
Summary:
Add type to FileSpec::PathSyntax enum to decrease size for
FileSpec on systems with 32 bit pointers.
Thanks to @zturner for pointing this out.
Differential Revision: https://reviews.llvm.org/D39574
llvm-svn: 317327
Summary:
This mechanism was mostly redundant with the file-based .categories
mechanism, and it was interfering with it, as any test which implemented
a getCategories method would not inherit the filesystem categories.
This patch removes it. The existing categories are preserved either by
adding a .categories file, or using the @add_test_categories decorator.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39515
llvm-svn: 317277
Now that the wathpoint tests have their own category, we can easily skip
them on devices which don't have watchpoint support. Therefore, we don't
need an android xfail on each of these tests.
llvm-svn: 317276
Summary:
macOS builds of LLDB use the bundle version from
`tools/driver/lldb-Info.plist`. That file hasn't been updated since the 4.0
release so the version we print provides no value. I also think that even if it
were up to date, that number has no meaning and displaying the version from the
LLVM tree is more valuable.
I know that Apple folks have some form of override for the clang version to
match the Xcode version, so it'd make sense for them to do the same for LLDB.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39429
llvm-svn: 317218
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D39128
<rdar://problem/34870417>
llvm-svn: 317182
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D38829
llvm-svn: 317180
dwarf&dwo versions were doing it, but gmodules and dsym weren't. All
this function does right now is pass OS=Android to make when targeting
android. This enables us to run dotest without manually passing --env
OS=Android.
llvm-svn: 317130
Summary:
std::queue is just a fancy wrapper around another container, so all we
need to do is to delegate to the it.
Reviewers: jingham, EricWF
Subscribers: srhines, mgorny, lldb-commits, eugene
Differential Revision: https://reviews.llvm.org/D35666
llvm-svn: 317099
Summary:
It is not presently used, and it's quite dangerous to use -- it assumes the
integer is an osx kern_return_t, but very few of the integers we have lying
around are mach kernel error codes. The error can still be used to a
mach error using a slightly longer (but more explicit) syntax.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35305
llvm-svn: 317093
This version relies on a newer and more convenient way
to use a class to implement a command. It has been in place
since early 2015, so it should be pretty safe to use.
llvm-svn: 317043
Most of the watchpoint tests are organized into subtrees, so we can use the
file-based .categories approach to annotate them. The exception are the
concurrent_events tests, which needed to be annotated on a per-test basis.
The motivation behind this is to provide an easy way to disable watchpoint
tests on systems where the watchpoint functionality is not present/unreliable.
llvm-svn: 317004
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the system libraries. Instead these libraries
were being manually added to each final target.
This changes moves the dependency management from the individual targets
to the lldbUtility module, which is consistent with how llvm does it.
The final targets will pick up these libraries as they will be a part of
the link interface of the module.
Technically, some of these dependencies could go into the host module,
as that's where most of the os-specific code is, but I did not try to
investigate which ones.
Reviewers: zturner, sylvestre.ledru
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39246
llvm-svn: 316997
The previous value was not sufficient for Pixel 2 phones. One would have
hoped that the newer phones are faster, but that does not seem to be the
case here.
llvm-svn: 316993
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Reviewers: jingham, EricWF
Subscribers: srhines, eugene, lldb-commits
Differential Revision: https://reviews.llvm.org/D35556
llvm-svn: 316992
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
Unified headers will be the only way to build applications in NDK r16,
and it also works with NDK r15.
This also bumps the minimum supported android version to 16.
llvm-svn: 316985
this test was using a single makefile to build two executables. This
setup, although not supported by Makefile.rules, happened to
work in most configurations, except when building with the android ndk
r16.
Here I move the building of the second executable to a separate
makefile, which is the solution other tests use for multiple targets.
llvm-svn: 316982
Versions of android before kitkat implemented pselect non-atomically,
which caused flakyness, as we were relying on it atomically setting the
signal mask to implement waiting for signals.
This patch implements a direct call to the the pselect kernel syscall,
which does not suffer from this problem. The code itself is not very
pretty, but fortunately the uglyness is contained in the
android version of the MainLoop::RunImpl::Poll function.
llvm-svn: 316915
Pavel Labath