Summary: The new API allows to find a list of compile units related to target/module.
Reviewers: aprantl, clayborg
Reviewed By: aprantl
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D48801
llvm-svn: 336200
that I used to sort it to scripts/sort-pbxproj.rb. It turns
out that Xcode will perturb the order of the file lists
every time we add a file, following its own logic, and unfortunately
we'll still end up with lots of merge conflicts when that tries
to merge to the github swift repositories. We talked this over
and we're going to keep it in a canonical state by running this
script over it when Xcode tries to reorder it.
llvm-svn: 336158
Summary:
Fixes the XCode builds that started failing when i added CompletionRequest.cpp/.h.
The patch is so large because XCode decided to write the lines back in its own order, but essentially we only added on e file.
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D48858
llvm-svn: 336154
Summary:
1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case
2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues.
Reviewers: asmith, labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48844
llvm-svn: 336147
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
Summary:
This patch updates a few MI commands using a new way of
handling an errors in lldb-mi and removes unnecessary
m_lldbResult variables.
Reviewers: aprantl, clayborg, labath
Reviewed By: aprantl, clayborg
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47992
llvm-svn: 336009
Summary:
This test makes sure we are able to read the shorter build-ids which are
generated by lld.
To make this work, I've extended lldb-test to print the UUID of the
loaded object file. I've renamed the lldb-test subcommand from
"module-sections" to "object-file" to reflect the fact it prints more
than just the sections.
I've also added the module Architecture to the output, so we could avoid
printing the entire symbol file information just to get the ArchSpec
details in the lc_version_min test (which was also the only test in it's
folder not using the module-sections command).
Reviewers: aprantl, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48646
llvm-svn: 335967
Summary:
The data structure is optimized for the case where the UUID size is <=
20 bytes (standard length emitted by the GNU linkers), but larger sizes
are also possible.
I've modified the string conversion function to support the new sizes as
well. For standard UUIDs it maintains the traditional formatting
(4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and
for longer UUIDs it will just repeat the last 6-byte block as long as
necessary.
I've also modified ObjectFileELF to take advantage of the new UUIDs and
avoid manually padding the UUID to 16 bytes. While there, I also made
sure the computed UUID does not depend on host endianness.
Reviewers: clayborg, lemo, sas, davide, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D48633
llvm-svn: 335963
The code was creating a StringRef to a temporary std::string. The
solution is to just drop the .str() from the original StringRef.
This manifested it self as the new TestCompletions test failing in some
configurations.
llvm-svn: 335960
Now that we have gmock, we can use its matchers to better express the
test assertions. The main advantage of this is that when things fail,
the test will now print the expected and actual lists of completed
strings instead of just a not-very-helpful "false is not true" message.
llvm-svn: 335955
Summary:
The test fails because we don't rewrite the slash behind `foo` to the OS specific
separator (as the completion API doesn't support this kind of rewriting). However,
we assume that this part of the string is rewritten in the test case, which broke
on Windows.
Reviewers: stella.stamenova
Reviewed By: stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48746
llvm-svn: 335934
This provides an efficient (at least on Posix platforms) way to offload to the
target process the search & loading of a library when all we have are the
library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
Summary: On Windows, the newer DIA SDKs end up producing function names that contain the return type as well. This means that the function name returned in the test will contain the return type (int) in addition to the name of the function and the type of the input (a(int)). To account for the possibility of both, the test should pass if the function name matches either pattern.
Reviewers: zturner, asmith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48654
llvm-svn: 335906
Summary:
To successfully open a core file, we need to have LLVM built with
support for the relevant target. Right now, if one does not have the
appropriate targets configured, the tests will fail.
This patch uses the GetBuildConfiguration SB API to inform the test (and
anyone else who cares) about the list of supported LLVM targets. The
test then uses this information to approriately skip the tests.
Reviewers: clayborg, jingham
Subscribers: martong, lldb-commits
Differential Revision: https://reviews.llvm.org/D48641
llvm-svn: 335859
Summary:
This patch fixes a problem with retrieving a function symbol by an
address in a nested block. In the current implementation of
ResolveSymbolContext function it retrieves a symbol with
PDB_SymType::None and then checks if found symbol's tag equals to
PDB_SymType::Function. So, if nested block's symbol was found,
ResolveSymbolContext does not resolve a function.
Reviewers: asmith, labath, zturner
Reviewed By: asmith, labath
Differential Revision: https://reviews.llvm.org/D47939
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>
llvm-svn: 335822
When running the test suite with .debug_names a bunch of tests were
failing because GetCompleteObjCClass was not yet implemented for
DebugNamesDWARFIndex. This patch adds the required logic.
We use the .debug_names to find the Objective-C class and then rely on
DW_AT_APPLE_objc_complete_type to find the complete type. If we can't
find it or the attribute is not supported, we return a list of potential
complete types.
Differential revision: https://reviews.llvm.org/D48596
llvm-svn: 335776
This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes.
llvm-svn: 335710
Summary:
During the previous attempt to generalize the UUID class, it was
suggested that we represent invalid UUIDs as length zero (previously, we
used an all-zero UUID for that). This meant that some valid build-ids
could not be represented (it's possible however unlikely that a checksum of
some file would be zero) and complicated adding support for variable
length build-ids (should a 16-byte empty UUID compare equal to a 20-byte
empty UUID?).
This patch resolves these issues by introducing a canonical
representation for an invalid UUID. The slight complication here is that
some clients (MachO) actually use the all-zero notation to mean "no UUID
has been set". To keep this use case working (while making it very
explicit about which construction semantices are wanted), replaced the
UUID constructors and the SetBytes functions with named factory methods.
- "fromData" creates a UUID from the given data, and it treats all bytes
equally.
- "fromOptionalData" first checks the data contents - if all bytes are
zero, it treats this as an invalid/empty UUID.
Reviewers: clayborg, sas, lemo, davide, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D48479
llvm-svn: 335612
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
This method does one of two things:
1. finds a minimum os deployment version # in a Mach-O load
command and saves the three parts in the m_sdk_version, or
2. finds no valid min os version # load command, pushes a
sentinel value on the m_sdk_version vector so we don't search
the same load commands multiple times.
There was a little bug when we found a load command with
a version of 0.0.0 - the method would not add anything to
the m_sdk_version vector but would declare that a success.
It would not push the sentinel value to the vector.
There was code later in the method which assumed that
the vector always had a sentinel value, at least, and that
code could crash when this method was called back when
evaluating a Swift expression. (these version #'s are
fetched lazily so it wouldn't happen when the object file
was parsed, only when doing an expression that needed
the version #).
<rdar://problem/41372699>
llvm-svn: 335556
pseudo_barrier_wait() begins by decrementing an atomic variable. Since
these are always_inline in libc++, there is no line table anchor to
break on before we decrement it. This meant that on gcc we stopped after
the variable has been decremented, which meant that thread2 could have
exited, violating the test setup. On clang this wasn't a problem
because it generated some line table entries for the do{}while(0) loop
in the macro, so we still ended up stopping, before we touched the
variable.
I fix this by adding a dummy statement before the pseudo_barrier_wait()
command and setting the breakpoint there.
llvm-svn: 335476
This reverts r335432 because remove_dots() is expensive and measuring
its impact showed an observable performance regression
(https://reviews.llvm.org/D45977#1078510).
llvm-svn: 335448
Removing redundant components from the path seems pretty harmless.
Rather than checking whether this is necessary and then actually doing
so, always invoke remove_dots to start with a normalized path.
llvm-svn: 335432
Filenames with test results contain only the class name which makes it more
difficult to find it if the same class name is present in multiple *.py files.
packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py
-class ReturnValueTestCase(TestBase):
+class StepAvoidsNoDebugTestCase(TestBase):
as ReturnValueTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
-class CreateDuringStepTestCase(TestBase):
+class CrashDuringStepTestCase(TestBase):
as CreateDuringStepTestCase is already present in:
packages/Python/lldbsuite/test/functionalities/thread/create_during_step/TestCreateDuringStep.py
packages/Python/lldbsuite/test/functionalities/thread/step_until/TestStepUntil.py
-class TestCStepping(TestBase):
+class StepUntilTestCase(TestBase):
as TestCStepping is already present in:
packages/Python/lldbsuite/test/lang/c/stepping/TestStepAndBreakpoints.py
llvm-svn: 335431
Replaces custom implementations of append and prepend with calls to
llvm's path library. This is part of a series of patches (started in
D48084) to delegate common operations to llvm::sys::path.
llvm-svn: 335430
Fixes include:
- fix all lint errors
- add code that will automatically register and LLDB command classes by detecting the classes and any classes that have a "register_lldb_command" function
- automatically fill in the correct module name when registering commands
- automatically fill in the class name when registering command
llvm-svn: 335401
libstdc++ will soon be dropped from the android NDK. This patch makes
sure we are prepared for that by using libc++ in tests by default (i.e.,
except for libstdc++ data formatter tests).
Only a couple of small tweaks were needed to make this work:
- Add the libc++ include paths to CXXFLAGS only. This was necessary to
make the tests compile with -fmodules. The modules tests have been
disabled, but this way, they will be ready for them if they are
enabled.
- in one test I had to add an explicit std::string copy to make sure the
copy constructor is there for the expression evaluator to find it.
llvm-svn: 335344
Our DWARF parsing code had a workaorund for Objective-C "self" not
being marked as artifial by the compiler. Clang has been doing this
since 2010, so let's just drop the workaround.
llvm-svn: 335313
Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.
This reverts the #ifdef part of the above patch, while keeping the cmake
parts.
llvm-svn: 335260
I've made the code accept only 16 byte UUIDs, which is technically not
NFC (previously it would also accept 20 byte ones, but use only the
first 16 bytes), but this should be more correct as mac UUIDs are always
16 byte long.
llvm-svn: 335247
Instead of a separate GetBytes + GetByteSize methods I introduce a
single GetBytes method returning an ArrayRef.
This is NFC cleanup now, but it should make handling arbitrarily-sized
UUIDs cleaner, should we choose to go that way. I also took the
opportunity to add some unit tests for this class.
llvm-svn: 335244
Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linking of the Python plugin in liblldb. This
plugin is already included as a part of LLDB_ALL_PLUGINS variable.
llvm-svn: 335236
These tests are extremely environment-dependent. if the environment is
not module-enabled (which is the likely scenario), they won't test
anything. If one happens to have a module-enabled libc++, then the he
will start running into problems.
The first one is that the debug info in pcm file contains relocations
that ObjectFileELF doesn't handle (particularly on non-x86
architectures), but even after that is resolved, it seems we still are
unable to pull debug info out of the pcm file. I've filed pr37893 to
track that, and I am disabling gmodules tests on linux until these
issues are resolved.
llvm-svn: 335235
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g. <cstdio> defines only
std::printf and not ::printf).
This consolidates the tests where this was an issue to always include
the <c???> version of the headers and prefixes the symbols with std:: as
necessary.
Apart from that, there is no functional change in the tests.
llvm-svn: 335149
The problem was that with libc++ the std::unique_lock declaration was
completely inlined, so there was no line table entry in the main.cpp
file to set a breakpoint on. Therefore, the breakpoint got moved to the
next line, but that meant the test would deadlock as the thread would
stop with the lock already held.
I fix that issue by adding a dummy statement before the std::unique_lock
line to anchor the breakpoint.
I think this should fix the issue because of which this test was
disabled on darwin, but someone should verify that before enabling it.
llvm-svn: 335132
Sign-extension of small types (e.g. short) was not handled correctly.
The reason for that was that when we were assigning the a value to the
Scalar object, we would accidentally promote the type to int (even
though the assignment code in AssignTypeToMatch tried to cast the value
to the appropriate type, it would still invoke the "int" version of
operator=). Instead, I use the APInt version of operator=, where the
bitwidth is specified explicitly. Among other things, this allows us to
fold the individual size cases into one.
llvm-svn: 335114
Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47384 did for clang, by
moving the path computation into the python plugin and modifying
SBHostOS class to call into this module for ePathTypePythonDir.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D48215
llvm-svn: 335104
passes to the recursive search function so we only recursively
search the kext bundle directory, instead of its parent directory.
<rdar://problem/41227170>
Differential Revision: https://reviews.llvm.org/D48302
llvm-svn: 335079
Summary:
OnExit ensures we call `ResetDeclMap` before this method ends. However,
we also have a few manual calls to ResetDeclMap in there that are actually unnecessary
because of this (calling the method multiple times has no effect). This patch also moves
the class out of the method that we can reuse it for the upcoming method that handles
parsing for completion.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48337
llvm-svn: 335078
StringConvert was the only non-Utility dependency of this class. Getting
rid of it means it will be easy to move this class to a lower layer.
While I was in there, I also added a couple of unit tests for the Scalar
string conversion function.
llvm-svn: 335060
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of functions, each returning a single path
kind. This makes it easy to move the python-path function into a
specific plugin in a follow-up commit.
All the users of GetLLDBPath were converted to call specific functions
instead. Most of them were hard-coding the enum value anyway, so this
conversion was simple. The only exception was SBHostOS, which I've
changed to use a switch on the incoming enum value.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48272
llvm-svn: 335052
The issue was that there was no dependency from lldb-suite target to liblldb in
the no-framework scenario. This caused the finish-swig target to be executed
prematurely and fail (because it cannot copy liblldb to the python folder). On
other platforms this did not matter because there just creates a symlink.
The extra lldb-suite -> liblldb edge should fix this. Technically, I could add
this just to the !framework case as the framework target will take care of the
transitive dep, but it seemed more clear to make the dep unconditional.
llvm-svn: 335047
Summary:
We weren't using the Info.plist template in resources previously.
When using that template, some of the key's values weren't being populated
because some variables were not being defined. In one case, CMake didn't
like the substring expansion syntax of CFBundleIdentifier so I got rid of that.
Differential Revision: https://reviews.llvm.org/D47792
llvm-svn: 335014
DynamicLoaderDarwinKernel plugin. Created a new function ReadMachHeader
and instead of reading through the target cached memory reader,
start by reading only a mach header sized chunk of memory, then
check it for a valid mach-o magic # and use the size of the load
commands to pre-fetch the entire load commands of the kext which
is the only thing we're going to read, instead of letting the generic
mach-o parser read it in 512 byte chunks.
Functionally this is doing exactly the same thing as before, but by
cutting down on the # of packets going back and forth, even on a
local connection it's close to a quarter faster than it was before.
<rdar://problem/38570146>
llvm-svn: 334995
We didn't add the remaining path behind the '~' to the completion string,
causing it to just complete directories inside the user home directory. This
patch just adds the directory of the remaining path if there is one.
Fixes rdar://problem/40147002
llvm-svn: 334978
Summary:
In this patch I aim to do the following:
1) Create an lldb-framework target that acts as the target that handles generating LLDB.framework. Previously, liblldb acted as the target for generating the framework in addition to generating the actual lldb library. This made the target feel overloaded.
2) Centralize framework generation as much as it makes sense to do so.
3) Create a target lldb-suite, which depends on every tool and library that makes liblldb fully functional. One result of having this target is it makes tracking dependencies much clearer.
Differential Revision: https://reviews.llvm.org/D48060
llvm-svn: 334968
I actually did check that macos builds before committing, but this error
was in conditionally compiled code that did not seem to be used on my
machine.
I also fix a typo in the previous speculative NetBSD patch.
llvm-svn: 334955
Summary:
This has multiple advantages:
- we need only one function argument/instance variable instead of three
- no need to default initialize variables
- no custom parsing code
- VersionTuple has comparison operators, which makes version comparisons much
simpler
Reviewers: zturner, friss, clayborg, jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D47889
llvm-svn: 334950
of debugserver's xcode project file to reduce automerger issues
with the github swift repository of lldb where the order of these
entries has drifted significantly over the years.
llvm-svn: 334873
sections of lldb's xcode project file to reduce automerger
issues with the github swift repository of lldb where
the order of these entries has drifted significantly
over the years.
llvm-svn: 334872
The second makefile that was added has implicit rules which meant
that secondprog.cpp would be built once into a secondprog binary,
but it would also be compiled as a.out overwriting the main binary.
This lead to spurious failures.
This commit simplifies the Makefile to build only once with the correct
executable name.
llvm-svn: 334861
Summary: This reverts commit r334245 because it duplicates
functionality of Status::AsCString used in SBError.
Reviewers: aprantl, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D48212
llvm-svn: 334860
The toolchain in Xcode 10 uses a new LC_BUILD_VERSION entry to identify
simulator binaries. Add support for reading those to debugserver.
The exisitng test testing that code is currently failling when run
with Xcode 10, no need for a new test.
llvm-svn: 334784
on darwin systems and re-execing itself, to creating two
separate test programs; lldb runs the first program and it
exec's the second.
Support for compiling for i386 is going away.
llvm-svn: 334783
On macOS 10.14, debugserver needs to have an entitlement do be
allowed to debug processes. Adding this to both the Xcode and
cmake build system. This shouldn't have any impact on previous
OSs.
llvm-svn: 334772
I've been using this script on a couple machines and it seems to work
so I'm putting it out there, maybe other people will find it useful.
It is strongly inspired from a similar script in the delve project.
llvm-svn: 334743
This fixes a silly bug where we were accidentally freeing the memory
used to store the decompressed .debug_names data. I had actually
considered this scenario when writing the class and put appropriate
precautions in place -- I just failed to wire it all up correctly.
This was only an issue for compressed sections because in case of
uncompressed ones we would access the data straight out of the mmapped
object file.
llvm-svn: 334717
r334615 changed the the value of FileSpec.IsRelative("/") for windows
path syntax. We previously considered it absolute but now it is
considered relative (I guess because it's interpretation depends on the
current drive).
This cause a failure in PathMappingList test, which assumed that "/"
will not get remapped as it is an absolute path. As this is no longer
true on windows, I replace "/" with a really absolute path.
llvm-svn: 334702
This unbreaks the cmake build. Other plugins also use the include paths
starting with Plugins/..., so I am hoping this will work for the xcode build
too.
llvm-svn: 334697
SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.
At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.
These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.
llvm-svn: 334663
Summary:
test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails.
During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable).
This change also fixes both the positive and negative cases on Windows. There were a few issues:
1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success.
2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF).
3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string.
Reviewers: labath, zturner, asmith, jingham
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48050
llvm-svn: 334642
This patch adds a data formatter for NSDecimalNumber. The latter is a
Foundation object used for representing and performing arithmetic on
base-10 numbers that bridges to Decimal.
Differential revision: https://reviews.llvm.org/D48114
llvm-svn: 334638
With the recent changes in FileSpec to use LLVM's path style, it is
possible to delegate a bunch of common path operations to LLVM's path
helpers. This means we only have to maintain a single implementation and
at the same time can benefit from the efforts made by the rest of the
LLVM community.
This is part one of a set of patches. There was no obvious way to split
this so I just worked from top to bottom.
Differential revision: https://reviews.llvm.org/D48084
llvm-svn: 334615
Summary:
This patch adds a modulemap which allows compiling the lldb headers into C++ modules
(for example in builds with LLVM_ENABLE_MODULES=On).
Even though most of the affected code has been cleaned up to work with the more strict
C++ module semantics, there are still some workarounds left in the current modulemap
(the most obvious one is the big `lldb` wrapper module).
It also moves the Obj-C++ files in lldb to their own subdirectories. This was necessary
because we need to filter out the modules flags for this code.
Note: With the latest clang and libstdc++ it seems necessary to have a STL C++ module
to get a working LLVM_ENABLE_MODULES build for lldb. Otherwise clang will falsely
detect ODR violations in the textually included STL code inside the lldb modules.
Reviewers: aprantl, bruno
Reviewed By: aprantl, bruno
Subscribers: mgorny, yamaguchi, v.g.vassilev, lldb-commits
Differential Revision: https://reviews.llvm.org/D47929
llvm-svn: 334611
Summary:
This source files emits all kind of compiler warnings on different platforms. As the source code
in the file is generated and we therefore can't actually fix the warnings, we might as well disable
them.
Reviewers: aprantl, davide
Reviewed By: davide
Subscribers: davide, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D48096
llvm-svn: 334557
Summary: This patch allows building a C++ module for the lldb-mi headers.
Reviewers: bruno, aprantl
Reviewed By: aprantl
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D47996
llvm-svn: 334549
This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.
In the end, I think this makes for a more idiomatic and platform
agnostic API. Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms. There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.
llvm-svn: 334518
This method is used to find complete definitions of a type when one
parses a compile unit with only forward declaration available.
Since it is only accessed from DWARFASTParserClang, it was not
possible/easy to trigger this codepath from lldb-test. Therefore, I
adapt add a debug-names variant to an existing dotest test to cover this
scenario.
llvm-svn: 334516
Some gcc versions (circa 4.9) do not accept initializing Expected
objects containing a reference to a function from a function.
Change the Expected object to contain function pointers to work around
this.
llvm-svn: 334501
The motivation for this is to be able to Dwarf index ability to look up
variables within a given compilation unit. It also fits in with the
patch in progress at D47939, which will add the ability to look up
funtions using file+line pairs.
The verification of which lldb-test options can be used together was
getting a bit unwieldy, so I moved the logic out into a separate
function.
llvm-svn: 334498
Apparently some compilers generate incomplete debug information which
caused the updated test to fail. Therefore I've extracted the new check
into a separate test case with the necessary decorators.
llvm-svn: 334456
Before Pavel's change in r334181, we were printing too many global
variables. This patch updates the test suite to ensure we don't regress
again in the future.
rdar://problem/29180927
llvm-svn: 334454
There was no way to find out what's wrong if SBProcess SBTarget::LoadCore(const char *core_file) failed.
Additionally, the implementation was unconditionally setting sb_process, so it wasn't even possible to check if the return SBProcess is valid.
This change adds a new overload which surfaces the errors and also returns a valid SBProcess only if the core load succeeds:
SBProcess SBTarget::LoadCore(const char *core_file, SBError &error);
Differential Revision: https://reviews.llvm.org/D48049
llvm-svn: 334439
Summary: Check case when _M_t child member is not present.
Reviewers: labath, tberghammer
Reviewed By: labath, tberghammer
Differential Revision: https://reviews.llvm.org/D47932
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>.
llvm-svn: 334411
The getDIESectionOffset function is not correct for split dwarf files
(and will probably be removed in D48009).
This patch implements correct section offset computation for split and
non-split compile units -- we first need to check if the referenced unit
is a skeleton unit, and if it is, we add the die offset to the full unit
base offset (as the full unit is the one which contains the die).
llvm-svn: 334402
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.
Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".
Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.
Reviewers: zturner, erik.pilkington
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47887
llvm-svn: 334399
My previous patch made this include unconditional. However, it seems it
is not available everywhere. This patch makes us include it only in
configurations we really need it, which should be enough to unblock the
bots.
llvm-svn: 334397
Summary:
Instead of hardcoding a list of platforms where libedit is known to have
wide char support we detect this in cmake. The main motivation for this
is attempting to improve compatibility with different versions of
libedit, as the interface of non-wide-char functions varies slightly
between versions.
Reviewers: krytarowski, uweigand, jankratochvil, timshen, beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47625
llvm-svn: 334393
Summary:
Default copy/move constructors and assignment operators leave wrong m_sets[i].registers pointers.
Made the class movable and non-copyable (it's difficult to imagine when it needs to be copied).
Reviewers: clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D47728
llvm-svn: 334282
r334215 changed the error message the tool prints for invalid thread
arguments to -exec-next command. This adjust the test to match that.
llvm-svn: 334279
This also fixes a bug where SymbolFileDWARF was returning the same
function multiple times - this can happen if both mangled and demangled
names match the regex. Other lookup lookup functions had code to handle
this case, but it was forgotten here.
llvm-svn: 334277
Summary:
This patch implements the non-regex variant of GetFunctions. To share
more code with the Apple implementation, I've extracted the common
filtering code from that class into a utility function on the DWARFIndex
base class.
The new implementation also searching the accelerator table multiple
times -- previously it could happen that the apple table would return
the same die more than once if one specified multiple search flags in
name_type_mask. This way, I separate table iteration from filtering, and
so we can be sure each die is inserted at most once.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47881
llvm-svn: 334273
Summary:
The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature.
SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0).
To fix the problem this patch renews the sequence on each address gap.
Reviewers: asmith, zturner
Reviewed By: asmith
Subscribers: aleksandr.urakov, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47708
llvm-svn: 334260
This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition. The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum. The second controls more flags-like values.
This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before. This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.
llvm-svn: 334221
Instead of checking if code compiles, I think it is a better to check
if the symbol exists. This is simpler and should do the same thing.
Differential Revision: https://reviews.llvm.org/D47897
llvm-svn: 334219
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
When loading kexts in PlatformDarwinKernel, we use the BundleID as the
filename to to create shared modules. In GetSharedModule we call
ExamineKextForMatchingUUID for any BundleID it finds that is a match, to
see if the UUID is also a match. Until now we were using
Host::ResolveExecutableInBundle which calls a CoreFoundation API to
obtain the executable. However, it's possible that the executable has a
variant suffix (e.g. foo_development) and these files were ignored.
This patch replaces that call with logic that looks for all the binaries
in the bundle. Because of the way ExamineKextForMatchingUUID works, it's
fine to try to load executables that are not valid and we can just
iterate over the list until we found a match.
Differential revision: https://reviews.llvm.org/D47539
llvm-svn: 334205
This implements just one of the GetTypes overloads. The other is not
testable from lldb-test so I'm leaving it unimplemented until I figure
out what to do with testing.
llvm-svn: 334190
Summary:
It possible that a single module has indexed and non-indexed compile
units. In this case, we can use the fast indexed lookup for the first
ones and fall back to the manual index for the others.
This patch implements this functionality by adding a units_to_avoid
argument to the ManualDWARFIndex constructor. Any units present in that
list will be ignored for the purposes of manual index. Individual
DebugNamesDWARFIndex then always consult both the manual fallback index
as well as the index in the .debug_names section.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47832
llvm-svn: 334185
Summary:
This patch adds the ability to lookup variables to the DWARF v5 index
class.
During review we discovered an inconsistency between how the existing
two indexes handle looking up qualified names of the variables:
- manual index would return a value if the input string exactly matched
the demangled name of some variable.
- apple index ignored the context and returned any variable with the
same base name.
So, this patch also rectifies that situation:
- it removes all context handling from the index classes. The
GetGlobalVariables functions now just take a base name. For manual
index, this meant we can stop putting demangled names into the
variable index (this matches the behavior for functions).
- context extraction is put into SymbolFileDWARF, so that it is common
to all indexes.
- additional filtering based on the context is also done in
SymbolFileDWARF. This is done via a simple substring search, which is
not ideal, but it matches what we are doing for functions (cf.
Module::LookupInfo::Prune).
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47781
llvm-svn: 334181
Summary:
This patch adds the skeleton for implementing the DWARF v5 name index
class. All of the methods are stubbed out and will be implemented in
subsequent patches. The interesting part of the patch is the addition of
a "ignore-file-indexes" setting to the dwarf plugin which enables a
user to force using manual indexing path in lldb (for example as a
debugging aid). I have also added a test that verifies that file indexes
are used by default.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: mgorny, mehdi_amini, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47629
llvm-svn: 334088
Skip all Python-based tests as unsupported when LLDB_DISABLE_PYTHON is
enabled. Otherwise, those tests simply fail being unable to import lldb
module.
Differential Revision: https://reviews.llvm.org/D47812
llvm-svn: 334080
Summary:
The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature.
SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0).
To fix the problem this patch renews the sequence on each address gap.
Reviewers: asmith, zturner
Reviewed By: asmith
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47708
llvm-svn: 334030
Summary: This test was failing sporadically on windows because the order in which the symbols are generated was different between builds. To fix the test, we need to run FileCheck twice - once for each set of symbols we want to verify. The test only runs on Windows.
Reviewers: asmith, zturner, labath
Subscribers: stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D47746
llvm-svn: 334025
Summary:
This is split off from D47265 where I needed to be able to invoke every test
with -f. That patch is kinda dead now, but this part seems like a good
cleanup anyway.
The problem with inline tests was in the way we were adding methods to
the class, which left them with an incorrect __name__ property. This
prevented dotest from finding them with -f.
I fix this with (what I think is) the correct way of dynamically
creating classes -- passing the list of methods during type construction
instead of fixing up the class afterwards. Among other things this has
the advantage of not needing to do anything special for debug info
variants. As our test method will be visible to the metaclass, it will
automagically do the multiplication for us.
Reviewers: JDevlieghere, aprantl, tberghammer
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47579
llvm-svn: 334009
Now that Apple index determines method-ness straight from the debug
info, we don't need to resolve the functions into SymbolContexts inside
the Index classes. This removes the need for callback arguments and
allows us to pull the common parts out of the two implementations of
these functions back into the SymbolFileDWARF class.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47147
llvm-svn: 334004
The warning started firing after r333923, which added new builtin
types (fixed point types) into clang.
This patch merely silences the warning to unblock our integrate, does
not aim to support the new types in lldb.
llvm-svn: 333999
If BuildAddressRangeTable called ExtractDIEsIfNeeded(false), then another
thread started processing data from m_die_array and then the first thread
called final ClearDIEs() the second thread would crash.
It is also required without multithreaded debugger using DW_TAG_partial_unit
for DWZ.
Differential revision: https://reviews.llvm.org/D40470
llvm-svn: 333987
Instead of assuming that SWIG generated files (e.g. lldb.py) will live
in scripts, we should set it to $LLDB_PYTHON_TARGET_DIR. This variable is set to
scripts, except when building LLDB.framework when it is set to
LLDB_FRAMEWORK_DIR.
Differential Revision: https://reviews.llvm.org/D47742
llvm-svn: 333968
Summary:
The default name for a compiler output on Linux is `a.out`,
while on Windows it's `a.exe`. But if we add option `-o a.exe`,
the compiler will create the executable `a.exe` on the both systems.
Reviewers: aprantl, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: ki.stfu, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D47679
llvm-svn: 333963
Host depended on clang because HostInfo had a function to get
the directory where clang was installed. We move this over to
the clang expression parser plugin where it's more at home.
Differential Revision: https://reviews.llvm.org/D47384
llvm-svn: 333933
Change the syntax of the malloc and free commands in lldb-test's
ir-memory-map subcommand to:
<malloc> ::= <label> = malloc <size> <alignment>
<free> ::= free <label>
This should make it easier to read and extend tests in the future, e.g
to test IRMemoryMap::WriteMemory or double-free behavior.
Differential Revision: https://reviews.llvm.org/D47646
llvm-svn: 333930
Add OpenBSD python module in order to support unit tests.
Reviewers: labath, zturner
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D47692
llvm-svn: 333888
Summary:
When searching for methods only, we need to do extra work to make sure
the functions we get from the apple tables are indeed methods.
Previously we were resolving the DIE into a SymbolContext and then
checked whether the enclosing CompilerDeclContext is a
class (or struct, or union).
This patch changes that to operate on the debug info directly. This
should be:
- simpler
- faster
- more consistent with the ManualDWARFIndex (which does the same check,
only at indexing time).
What we lose this ways is for the language plugin to have a say in what
it considers to be a "class", but that's probably more flexibility than
we need (and if we really wanted to do that in the future, we could
implement a more direct way to consult the plugin about this).
This also fixes the find-method-local-struct test, which was failing
because we were not able to construct a CompilerDeclContext for a local
struct correctly.
As a drive-by, I rename the DWARFDIE's IsStructClassOrUnion method to
match the name on the CompilerDeclContext class.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47470
llvm-svn: 333878
On Darwin, the binary's symbol table points to debug info in object
files -- potentially object files within a static library. Such a
library may have multiple entries with the same name, distinguished
only by timestamp.
The code was already _attempting_ to handle this case (see the code in
ObjectContainerBSDArchive::Archive::FindObject which disambiguates via
timestamp). But, unfortunately, while the timestamp was taken into
account on the _first_ lookup, the result was then cached in a map
keyed only off of the path.
Added the timestamp to the cache, and added a test case.
Differential Revision: https://reviews.llvm.org/D47660
llvm-svn: 333813
Summary: One of the tests is failing to build because it needs GS-, the second test does not correctly match all the expected function names because newer DIA SDKs annotate the function names with their return type and inputs (e.g. "static long `anonymous namespace'::StaticFunction(int)")
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47653
llvm-svn: 333790
Summary: Skip the new break-insert test on Windows because it hangs and so the test suite never completes. All other lldb-mi tests in the test suite are also skipped on windows
Reviewers: asmith, aprantl, polyakov.alex
Reviewed By: aprantl
Subscribers: ki.stfu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47651
llvm-svn: 333789
In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.
This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.
Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.
rdar://problem/40254997
llvm-svn: 333786
It's been pointed out in https://reviews.llvm.org/D47646 that lldb-test
fails to create a usable process on Windows when running this test.
llvm-svn: 333785
Summary:
Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are:
1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)
What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped
What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped
The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching.
HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang).
This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate.
Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496
Reviewers: asmith, labath, zturner, jingham
Reviewed By: zturner, jingham
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47609
llvm-svn: 333781
Summary:
The LLDB.framework generated when building with CMake + Ninja/Make is
completely missing the clang headers. Although the code to copy them exists, we
don't even generate them unless we're building LLDB standalone.
Reviewers: clayborg, labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47612
llvm-svn: 333777
This adds a new command to the ir-memory-map tester:
free <allocation-index>
The argument to free is an index which identifies which live allocation
to free. Index 0 identifies the first live allocation in the address
space, index 1 identifies the second, etc. where the allocations are
sorted in increasing order.
For illustrative purposes, assume malloc returns monotonically
increasing addresses. Here are some examples of how free would work:
Example 1
---------
malloc 16 1
malloc 32 1
free 1 //< Free the 32-byte allocation.
free 0 //< Next, free the 16-byte allocation.
Example 2
---------
malloc 16 1
malloc 32 1
free 0 //< Free the 16-byte allocation.
free 0 //< Next, free the 32-byte allocation.
llvm-svn: 333700
r333583 introduced testing for IRMemoryMap's process-side allocations
(eAllocationPolicyProcessOnly). This adds support for the host-side
variety (eAllocationPolicyHostOnly).
llvm-svn: 333698
This prevents Malloc from allocating the same chunk of memory twice, as
a byproduct of an alignment adjustment which gave the client access to
unallocated memory.
Prior to this patch, the newly-added test failed with:
$ lldb-test ir-memory-map ... ir-memory-map-overlap1.test
...
Command: malloc(size=64, alignment=32)
Malloc: address = 0x1000cd080
Command: malloc(size=64, alignment=8)
Malloc: address = 0x1000cd0b0
Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0)
Differential Revision: https://reviews.llvm.org/D47551
llvm-svn: 333697
Fixes infinite recursion due to change in how FileSpec deals with
removing the last path component.
Fixes timout for TestMiniDumpNew.py
llvm-svn: 333666
This test was using unittest (not unittest2) as the test framework, and
it worked with dotest only by accident. Remove it as we have a much more
realistic example test in test/testcases/sample_test.
llvm-svn: 333640
Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As this doesn't seem to be used in the tree, this patch
removes the parameter entirely.
Reviewers: clayborg, jingham, labath
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere
Differential Revision: https://reviews.llvm.org/D46885
Patch by Tom Tromey <ttromey@mozilla.com>.
llvm-svn: 333639
rL145086 introduced m_die_array.shrink_to_fit() implemented by
exact_size_die_array.swap, it was before LLVM became written in C++11.
Differential revision: https://reviews.llvm.org/D47492
llvm-svn: 333636
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
When reading DBGSourcePathRemapping from a dSYM, we remove the last two
path components to make the source lookup more general. However, when
dealing with a relative path that has less than 2 components, we ended
up with an invalid (empty) FileSpec.
This patch changes the behavior of removeLastPathComponent to remove the
last path component, if possible. It does this by checking whether a
parent path exists, and if so using that as the new path. We rely
entirely on LLVM's path implementation to do the heavy lifting.
We now also return a boolean which indicates whether the operator was
successful or not.
Differential revision: https://reviews.llvm.org/D47495
rdar://37791687
llvm-svn: 333540
Summary:
Generating LLDB.framework when building with CMake+Ninja will copy the
lldb-private headers because public_headers contains them, even though we try
to make sure they don't get copied by removing root_private_headers from
root_public_headers.
This patch also removes SystemInitializerFull.h from the LLDB.framework headers when building with CMake.
Reviewers: compnerd, sas, labath, beanz, zturner
Reviewed By: labath
Subscribers: clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47278
llvm-svn: 333444
GetUnitDIEPtrOnly() needs to return pointer to the first DIE.
But the first element of m_die_array after ExtractDIEsIfNeeded(true)
may move in memory after later ExtractDIEsIfNeeded(false).
DWARFDebugInfoEntry::collection m_die_array is std::vector,
its data may move during its expansion.
Differential revision: https://reviews.llvm.org/D46810
llvm-svn: 333437
The lldb test suite is highly configurable. While part of this
configuration takes place at configure/build-time, a common scenario
involves running the test suite several times with different
configuration. For example, we might want to test the current lldb
against inferiors built with different compilers.
This configuration was already possible for lldb-dotest, but was lacking
for the lit counterpart. It is now possible to pass arguments to pass
arguments like this:
./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ -Ddotest-args="-foo;-bar"
llvm-svn: 333432
The framework argument was broken when I removed the generator
expressions upstream. I replaced $<TARGET_FILE_DIR:liblldb> with
${LLVM_LIBRARY_OUTPUT_INTDIR}) which is not correct.
rdar://40534649
llvm-svn: 333412
It's been failing since I enabled the test for non-darwin targets. I
made it reference the same bug as the linux core, as it's likely that
the root cause is the same.
llvm-svn: 333401
Summary:
This improves the process of cross-compiling from macOS to Linux
since these files aren't used / needed at all.
Reviewers: clayborg, labath
Subscribers: lldb-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D47420
llvm-svn: 333400
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module).
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47412
llvm-svn: 333345
Summary: This resolves unnecessary the header dependency from
Core to DataFormatters. Patch is necessary for the introduction of
C++ modules to the LLDB build system.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47409
llvm-svn: 333342
Summary:
It seems to me that files in include/lldb/API/ are headers that should
be exposed to liblldb users. Because SystemInitializerFull.h exposes details of
lldb_private, I think having it there is not the right thing to do. Since it's
only included from files in source/API, we should move it there and treat it as
private.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47342
llvm-svn: 333304
Several functions were passing a list of 8 NameToDIE arguments around.
This puts those variables in a struct and passes that instead, reducing
code duplication and the possibility of error (swapping two arguments
accidentally).
llvm-svn: 333264
As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning
a pointer to m_first_die should not permit using methods like GetFirstChild().
Differential revision: https://reviews.llvm.org/D47276
llvm-svn: 333224
This new DWARFBaseDIE is going to be used for DWARFUnit::GetUnitDIEOnly() as
other DIEs are unavailable that time so the caller should not have methods
available to access them.
This patch is only a mechanical split without any use of it.
Differential revision: https://reviews.llvm.org/D47275
llvm-svn: 333222
Now it's possible to set breakpoints before selecting a target, they
will be set to the dummy target and then copied to an each added one.
Patch by Alexander Polyakov!
Differential Revision: https://reviews.llvm.org/D46588
llvm-svn: 333205
Summary:
For lldb-server, it is sufficient to parse only the native object file
format for its target OS (no other file can be loaded into a running
process). This moves the object file initialization code into specific
initializer classes: lldb-test and liblldb get all object files;
lldb-server gets only one of them. For this to work, I've needed to
create a special SystemInitializer for use in lldb-server, instead of it
calling directly into the common one.
This reduces the size of lldb-server by about 2%, which is not
earth-shattering, but it's an easy win, and it helps.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47250
llvm-svn: 333182
Summary:
I think this makes sense for several reasons:
- better separation of concerns: DWARFUnit's job should be to provide a
nice interface to its users to access the unit contents.
ManualDWARFIndex can then use this interface to build an index and
provide it to its users.
- closer alignment with llvm parsers: there is no indexing equivalent in
llvm, and there probably never will be, as the index is very centered
around how lldb wants to access debug info. If we ever switch to
llvm's parser, this will allow us swap out DWARFUnit implementations
and keep indexing as-is.
- closer proximity of the indexing code to AppleDWARFIndex will make it
easier to keep the two in sync (e.g. right now the two use very
different algorithms to determine whether a DW_TAG_subroutine
represents a "method"). This is my primary motivation for making this
change now, but I am leaving this work to a separate patch.
The only interface change to DWARFUnit I needed to make was to add an
efficient way to iterate over the list of all DIEs. Adding this also
aligns us closer to the llvm parser.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47253
llvm-svn: 333178
The only reason this was here was so that Module could have a
function called CreateJITModule which created things in a special
order. Instead of making this specific to creating JIT modules,
I converted this into a template function that can create a module
for any type of object file plugin and just forwards arguments
through. Since the template is not instantiated in Core, the linker
(and header file) dependency moves to the point where it is
instantiated, which only happens in Expression. Conceptually, this
location also makes more sense for a dependency on ObjectFileJIT.
After all, we JIT expressions so it's no surprise that Expression
needs to make use of ObjectFileJIT.
Differential Revision: https://reviews.llvm.org/D47228
llvm-svn: 333143
The tests added in r332842 don't work on windows, because they do path
comparisons on strings, and on windows, the paths coming out of the
mappings had backslashes in them.
This switches comparisons to FileSpecs, so the results come out right.
llvm-svn: 333074
This call was originally being only made when launching for debug (as an
attempt to make sure we don't impart extra privileges on the launched
process), but after the debug and non-debug paths were merged, it made
it's way into generic code. This was causing problems in locked down
android environments which disallowed calling setgid even if it would be
a no-op. This prevented launching llgs from lldb-server platform.
Overall I'm not sure we should be calling setgid in the first place
(it seems random -- e.g. why don't we call setuid then as well).
However, all our other copies of launch code have it, so I choose to
keep it for now.
llvm-svn: 333073
Summary:
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.
Reviewers: rnk, zturner, lldb-commits
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45224
llvm-svn: 333049
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.
llvm-svn: 333041
Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, other sub-directories were added to include paths, or
Normalize those few instances to follow the style used by the rest of
the codebase, to make it easier to understand.
llvm-svn: 333035
Alexander Polyakov