Summary:
This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function,
making the code simpler and less memory unsafe.
There seems to be a assumption in some command objects that this parameter could be a nullptr,
but from what I can see the rest of the API doesn't actually allow this (and other command
objects and related code pieces dereference this parameter without any checks).
Especially CommandObjectRegexCommand has error handling code for a nullptr that is now gone.
Reviewers: davide, jingham, teemperor
Reviewed By: teemperor
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D49207
llvm-svn: 336955
Corrupted minidumps was leading to unpredictable behavior.
This change adds explicit consistency checks for the minidump early on. The
checks are not comprehensive but they should catch obvious structural violations:
streams with type == 0
duplicate streams (same type)
overlapping streams
truncated minidumps
Another early check is to make sure we actually support the minidump architecture
instead of crashing at a random place deep inside LLDB.
Differential Revision: https://reviews.llvm.org/D49202
llvm-svn: 336918
Summary: When ReadProcessMemory fails, bytes_read is sometimes set to a large garbage value. In that case, we need to set it back to zero before returning or the garbage value will be used to allocate memory later causing LLDB to crash with an out of memory error.
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner, asmith, stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D49159
llvm-svn: 336865
Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495
The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it.
Reviewers: asmith, zturner, aleksandr.urakov
Reviewed By: aleksandr.urakov
Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits
Differential Revision: https://reviews.llvm.org/D49111
llvm-svn: 336732
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:
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
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
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
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
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
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: 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
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
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
Summary:
- Fix #include path
- Fix warning:
````
error: format specifies type 'unsigned long long' but the argument has type 'uint64_t'
(aka 'unsigned long') [-Werror,-Wformat]
```
Reviewers: labath, javed.absar
Differential Revision: https://reviews.llvm.org/D47072
llvm-svn: 332733
It turns out these class still contained some os-specific functionality,
but I did not notice that originally, as it was #ifdef arm(64). This
adds back the __APPLE__ condition to these particular functions,
unbreaking arm builds on other OSs.
llvm-svn: 332710
Summary:
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). For the time
being I have created OS-independent definitions of these constants and
made the register context classes use those. Long term, the error
handling in these classes should be probably changed to use more
standard mechanisms such as Status or Error classes.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
Reviewers: jasonmolenda, aprantl, clayborg, javed.absar
Subscribers: mgorny, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D46934
llvm-svn: 332702
Summary: LLDB reads wrong registers on 64bit Windows because RegisterContextWindows_x64::GetRegisterInfoAtIndex returns wrong reference.
I encountered broken backtrace when the program stopped at function which does not have prologue code, such as compiled with '-fomit-frame-pointer'.
In this situation, CFA is equal to rsp but LLDB reads r9.
RegisterContextWindows_x64::GetRegisterInfoAtIndex depends the order of lldb_XXX_x86_64 values, but RegisterIndex/g_register_infos/g_gpr_reg_indices does not follow order.
In source/Plugins/Process/Utility/lldb-x86-register-enums.h
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8, ...
In source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, r8, r9, r10, ...
Patch by Kenji Koyanagi
llvm-svn: 332671
Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindows::DoResume, there's code that determines how many times to call ResumeThread based on whether the return value is greater than 0. Since the function returns -1 (as an unsigned int) on failure, this was getting stuck in an infinite loop if ResumeThread failed for any reason. The correct thing to do is check whether the return value is -1 and then return the appropriate error instead of ignoring the return value.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47020
llvm-svn: 332670
Summary:
The comments on this class were out of date with the implementation, and
the implementation itself was inconsistent with our usage of the Timeout
class (I started converting everything to use this class back in D27136,
but I missed this one). I avoid duplicating the waiting logic by
introducing a templated WaitFor function, and make other functions
delegate to that. This function can be also used as a replacement for
the unused WaitForBitToBeSet functions I removed, if it turns out to be
necessary.
As this changes the meaning of a "zero" timeout, I tracked down all the
callers of these functions and updated them accordingly. Propagating the
changes to all the callers of RunShellCommand was a bit too much for
this patch, so I stopped there and will continue that in a follow-up
patch.
I also add some basic unittests for the functions I modified.
Reviewers: jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D46580
llvm-svn: 331880
The function can only return in one of two ways: the Predicate value is
successfully set within the allotted time, or it isn't (the wait times
out). These states can be represented in the return value, and the extra
arg adds no value.
llvm-svn: 331458
This change adds support for two types of Minidump CodeView records:
PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html)
This is by far the most common record type.
ELF BuildID (found in Breakpad/Crashpad generated minidumps)
This would set a proper UUID for placeholder modules, in turn enabling
an accurate match with local module images.
Differential Revision: https://reviews.llvm.org/D46292
llvm-svn: 331394
This brings the LLDB configuration closer to LLVM's and removes visual
clutter in the source code by removing the @brief commands from
comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Previously, an attempt to read an unreadable address reported zeros.
Now, if DoReadMemory or DoWriteMemory encounters error then return 0
(bytes read or written) so that the error is reported to the user.
llvm.org/pr37190
llvm-svn: 330500
It was failing because the modules names were coming out as
C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on
windows.
There are two issues at play here:
- the first problem is that the paths in minidump were being parsed as a
host path. This meant that on posix systems the whole path was
interpreted as a file name.
- on windows the path was split into a directory-filename pair
correctly, but then when it was reconsituted, the last separator ended
up being a forward slash because SBFileSpec.fullpath was joining them
with '/' unconditionally.
I fix the first issue by parsing the minidump paths according to the
path syntax of the host which produced the dump, which should make the
test behavior on posix&windows identical. The last path will still be a
forward slash because of the second issue. We should probably fix the
"fullpath" property to do something smarter in the future.
llvm-svn: 330314
Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.
This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.
Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.
Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)
Example: Identify the module from a stack frame PC:
Before:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14
frame #1: 0x00167c79
frame #2: 0x00167e6d
frame #3: 0x7510336a
frame #4: 0x77759882
frame #5: 0x77759855
After:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll
Example: target modules list
Before:
error: the target has no associated executable images
After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll
NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)
Differential Revision: https://reviews.llvm.org/D45700
llvm-svn: 330302
Summary:
If the remote stub sends a specific error message instead of just a E??
code, we can use this to display a more informative error message
instead of just the generic "unable to attach" message.
I write a test for this using the SB API.
On the console this will show up like:
(lldb) process attach ...
error: attach failed: <STUB-MESSAGE>
if the stub supports error messages, or:
error: attach failed: Error ??
if it doesn't.
Reviewers: jingham, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45573
llvm-svn: 330247
Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.
This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D45480
llvm-svn: 330200
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.
llvm-svn: 330005
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
llvm-svn: 329891
There are plenty of ways attaching can go wrong. Having the server
report the exact error means we can give better feedback to the user.
(This patch does not do the second part, it only makes sure the
information is sent from the server.)
Triggering all possible error conditions in a test would prove
challenging, but there is one error that is very easy to reproduce
(attempting to attach while debugging), so I write a test based on that.
The test immediately exposed a bug where the m_send_error_strings field
was being used uninitialized (so it was sometimes true from the get-go),
so I fix that as well.
llvm-svn: 329803
Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Args class can be turned
into a lightweight arc+argv wrapper and moved into the lower lldb
layers.
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44306
llvm-svn: 329677
Summary:
When a MIG routine returns KERN_FAILURE, the demux function will release any OOL resources like ports. In this case, task_port and thread_port will be released twice, potentially resulting in use after free of the ports.
I don't think we can test this in any useful way
rdar://problem/37331387
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45011
llvm-svn: 328761
Summary:
We've had a mismatch in the checksum computation between the sender and
receiver. The sender computed the payload checksum using the wire
encoding of the packet, while the receiver did this after expanding
un-escaping and expanding run-length-encoded sequences. This resulted in
communication breakdown if packets using these feature were sent in the
ack mode.
Normally, this did not cause any issues since the only packet we send in
the ack-mode is the QStartNoAckMode packet, but I ran into this when
debugging the lldb-server tests which (for better or worse) don't use
this mode.
According to the gdb-remote documentation "The two-digit checksum is computed as
the modulo 256 sum of all characters between the leading ‘$’ and the
trailing ‘#’", it seems that our sender is doing the right thing here.
Therefore, I fix the receiver the match the sender behavior and add a
test.
With this bug fixed, we can see that lldb-server is sending a stop-reply
after receiving the "k" in the same way as debugserver does (but we
weren't detecting this because at that point the connection was dead
already). I fix that expectation as well.
Reviewers: clayborg, jasonmolenda
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D44922
llvm-svn: 328693
