Tests are failing and build is failing on windows and darwin.
Will fix and commit it later
-------------------------------------------------------------
Revert "xfailing minidump tests again ... :("
This reverts commit 97eade002c9e43c1e0d11475a4888083a8965044.
Revert "Fixing new Minidump plugin tests"
This reverts commit 0dd93b3ab39c8288696001dd50b9a093b813b09c.
Revert "Add the new minidump files to the Xcode project."
This reverts commit 2f638a1d046b8a88e61e212220edc40aecd2ce44.
Revert "xfailing tests for Minidump plugin"
This reverts commit 99311c0b22338a83e6a00c4fbddfd3577914c003.
Revert "Adding a new Minidump post-mortem debugging plugin"
This reverts commit b09a7e4dae231663095a84dac4be3da00b03a021.
llvm-svn: 283352
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arch that this supports is x86 64 bit
This is because I have only written a register context for that arch.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, amccarth, lldb-commits, modocache
Differential Revision: https://reviews.llvm.org/D25196
llvm-svn: 283259
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
Summary:
This is a register context converter from Minidump to Linux reg context.
This knows the layout of the register context in the Minidump file
(which is the same as in Windows FYI) and as a result emits a binary data
buffer that matches the Linux register context binary layout.
This way we can reuse the existing RegisterContextLinux_x86_64 and
RegisterContextCorePOSIX_x86_64 classes.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D24919
llvm-svn: 282529
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
This patch refactors the way the XState type is checked and, in order to
simplify the code, it removes the usage of the 'cpuid' instruction: just checking
if the ptrace calls done throuhg ReadFPR is enough to verify both if there is
HW support and if there is kernel support. Also the XCR0 bits are enough to check if
there is both HW and kernel support for AVX and MPX.
Differential Revision: https://reviews.llvm.org/D24764
llvm-svn: 282072
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.
In the process, I found a few opportunities for adding some
unit tests, so I added those as well.
Tested on Windows, Linux, and OSX.
llvm-svn: 281799
Summary:
This patch uses the instruction CPUID to verify that FXSAVE, XSAVE, AVX
and MPX are supported by the target hardware. In case the HW supports XSAVE,
and at least one of the extended register sets, it further checks if the
target software has the kernel support for such features, by verifying that
their XSAVE part is correctly managed.
Differential Revision: https://reviews.llvm.org/D24559
llvm-svn: 281507
Summary:
Added parsing of the MiscInfo data stream.
The main member of it that we care about is the process_id
On Linux generated Minidump (from breakpad) we don't have
the MiscInfo, we have the /proc/$pid/status from where we can get the
pid.
Also parsing the module list - the list of all of the loaded
modules/shared libraries.
Parsing the exception stream.
Parsing MinidumpStrings.
I have unit tests for all of that.
Also added some tests using a Minidump generated from Windows tools (not
from breakpad)
Reviewers: labath, zturner
Subscribers: beanz, lldb-commits
Differential Revision: https://reviews.llvm.org/D24385
llvm-svn: 281348
Summary:
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function
Reviewers: jingham, emaste, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24331
llvm-svn: 281191
This change does the following:
* Changes the signature for the continuation delegate method that handles
async structured data from accepting an already-parsed structured data
element to taking just the packet contents.
* Moves the conversion of the JSON-async: packet contents from
GDBRemoteClientBase to the continuation delegate method.
* Adds a new unit test for verifying that the $JSON-asyc: packets get
decoded and that the decoded packets get forwarded on to the delegate
for further processing. Thanks to Pavel for making that whole section of
code easily unit testable!
* Tightens up the packet verification on reception of a $JSON-async:
packet contents. The code prior to this change is susceptible to a
segfault if a packet is carefully crafted that starts with $J but
has a total length shorter than the length of "$JSON-async:".
Reviewers: labath, clayborg, zturner
Differential Revision: https://reviews.llvm.org/D23884
llvm-svn: 281121
Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.
This decreases the attach time to an android application by about 40%.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: https://reviews.llvm.org/D24236
llvm-svn: 280919
Most of these issues arose as a result of header re-ordering, but
it turned up a real bug, which is that MSVC doesn't support
__attribute__((packed)) or __attribute__((aligned)). This was
working before because there's a Windows header that #defines
__attribute__(x) to nothing. We should fix this by removing
that #define entirely, and dealing with the fallout separately
which may turn up even more bugs.
I fixed this by replacing them with the corresponding LLVM
macros which understand how to do these operations on all the
different compilers.
llvm-svn: 280757
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
This reverts commit rL280668 because the register tests fail on i386
Linux.
I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
bnd0 = {0x0000000000000000 0x0000000000000000}
bnd1 = {0x0000000000000000 0x0000000000000000}
bnd2 = {0x0000000000000000 0x0000000000000000}
bnd3 = {0x0000000000000000 0x0000000000000000}
unknown:
2 registers were unavailable.
"""
Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 < 76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 < 78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""
The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.
So I'm not sure what's the problem or where does it come from.
Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""
For some reason the registerSet.GetName() returns None.
llvm-svn: 280703
Summary:
The Intel(R) Memory Protection Extensions (Intel(R) MPX) associates pointers
to bounds, against which the software can check memory references to
prevent out of bound memory access.
This patch allows accessing the MPX registers:
* bnd0-3: 128-bit registers to hold the bound values,
* bndcfgu, bndstatus: 64-bit configuration registers,
This patch also adds read/write tests for the MPX registers in the register
command tests and adds a new subdirectory for MPX specific tests.
Signed-off-by: Valentina Giusti <valentina.giusti@intel.com>
Reviewers: labath, granata.enrico, lldb-commits, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24187
llvm-svn: 280668
This code represents the Week of Code work I did on bringing up
lldb-server LLGS support for Darwin. It does not include the
Xcode project changes needed, as we don't want to throw that switch
until more support is implemented (i.e. this change is inert, no
build systems use it yet. I've verified on Ubuntu 16.04, macOS
Xcode and macOS cmake builds).
This change does some minimal refactoring of code that is shared
with the Linux LLGS portion, moving it from NativeProcessLinux into
NativeProcessProtocol. That code is also used by NativeProcessDarwin.
Current state on Darwin:
* Process launching is implemented. (Attach is not).
Launching on devices has not yet been tested (FBS/BKS might
need a bit of work).
* Inferior waitpid monitoring and communication of exit status
via MainLoop callback is implemented.
* Memory read/write, breakpoints, thread register context, etc.
are not yet implemented. This impacts process stop/resume, as
the initial launch suspended immediately starts the process
up and running because it doesn't know it is supposed to remain
stopped.
* I implemented the equivalent of MachThreadList as
NativeThreadListDarwin, in anticipation that we might want to
factor out common parts into NativeThreadList{Protocol} and share
some code here. After writing it, though, the fallout from merging
Mach Task/Process into a single concept plus some other minor
changes makes the whole NativeThreadListDarwin concept nothing more
than dead weight. I am likely going to get rid of this class and
just manage it directly in NativeProcessDarwin, much like I did
for NativeProcessLinux.
* There is a stub-out call for starting a STDIO thread. That will
go away and adopt the MainLoop pselect-based IOObject reading.
I am developing the fully-integrated changes in the following repo,
which contains the necessary Xcode bits and the glue that enables
lldb-debugserver on a macOS system:
https://github.com/tfiala/lldb/tree/llgs-darwin
This change also breaks out a few of the lldb-server tests into
their own directory, and adds some $qHostInfo tests (not sure why
I didn't write those tests back when I initially implemented that
on the Linux side).
llvm-svn: 280604
Summary:
This is a Minidump parsing code.
There are still some more structures/data streams that need to be added.
The aim ot this is to be used in the implementation of
a minidump debugging plugin that works on all platforms/architectures.
Currently we have a windows-only plugin that uses the WinAPI to parse
the dump files.
Also added unittests for the current functionality.
Reviewers: labath, amccarth
Subscribers: tberghammer, danalbert, srhines, lldb-commits, dschuff
Differential Revision: https://reviews.llvm.org/D23545
llvm-svn: 280356
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
Summary:
e80f43fd78
greatly improved an API, but missed one more occurence of legacy usage.
This leads to:
if (extractor.GetHexBytes(&payload_bytes[0], payload_bytes.size(), '\xdd') != payload_bytes.size())
~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
/lldb/include/lldb/Utility/StringExtractor.h:151:5: note: 'GetHexBytes' declared here
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24064
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 280202
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a
little nicer (for example using StringRef member functions instead
of c-style strncmp and related functions) and generally safer
usage.
llvm-svn: 280139
MutableArrayRef<T> is essentially a safer version of passing around
(T*, length) pairs and provides some convenient functions for working
with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds
of string copies.
llvm-svn: 280000
This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locally with just 1 test failure which I was unable to figure out the
cause of. But it was also a massive changelist due to a trickle
down effect of changes.
So I'm starting over, using what I learned from the first time to
tackle smaller, more isolated changes hopefully leading up to
a full conversion by the end.
At first the changes (such as in this CL) will seem mostly
a matter of preference and pointless otherwise. However, there
are some places in my larger CL where using StringRef turned 20+
lines of code into 2, drastically simplifying logic. Hopefully
once these go in they will illustrate some of the benefits of
thinking in terms of StringRef.
llvm-svn: 279917
Summary:
This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock
(which is also not recursive). This required a couple of changes:
- The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring
the mutex, so these functions do not need to. All functions which now do not take a lock, take
an lock argument instead, to remind the caller of this fact.
- GetThreadSuffixSupported() was being called from locked and unlocked contexts (including
contexts where the process was running, and the call would fail if it did not have the result
cached). I have split this into two functions, one which computes the thread suffix support and
caches it (this one always takes the lock), and another, which returns the cached value (and
never needs to take the lock). This feels quite natural as ProcessGdbRemote was already
pre-caching this value at the start.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23802
llvm-svn: 279725
Summary:
The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting
hex-encoded data (as that was what the first implementation I replaced was using, but here we had
binary data to begin with. I thought the read/write register functions would be more useful if
they handled the hex-encoding themselves (all the other client functions provide the responses in
a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as
much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that
can be constructed from pretty much anything.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23659
llvm-svn: 279232
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
Summary:
Before this, each function had a copy of the code which handled appending of the thread suffix to
the packet (or using $Hg instead). I have moved that code into a single function and made
everyone else use that. The function takes the partial packet as a StreamString rvalue reference,
to avoid a copy and to remind the users that the packet will have undeterminate contents after
the call.
This also fixes the incorrect formatting of the QRestoreRegisterState packet in case thread
suffix is not supported.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23604
llvm-svn: 279040
Summary:
When saving/restoring registers the GDBRemoteRegisterContext class was manually constructing
the register save/restore packets. This creates appropriate helper functions in
GDBRemoteCommunicationClient, and switches the class to use those. It also removes what a
duplicate packet send in some of those functions, a thing that I can only attribute to a bad
merge artefact.
I also add a test framework for testing gdb-remote client functionality and add tests for the new
functions I introduced. I'd like to be able to test the register context changes in isolation as
well, but currently there doesn't seem to be a way to reasonably construct a standalone register
context object, so we'll have to rely on the end-to-end tests to verify that.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23553
llvm-svn: 278915
Despite its comment, the function is only used in the Client class, and its presence was merely
complicating mock implementation in unit tests.
llvm-svn: 278785
The commit started passing a nullptr port into GDBRemoteCommunication::StartDebugserverProcess.
The function was mostly handling the null value correctly, but it one case it did not check it's
value before assigning to it. Fix that.
llvm-svn: 278662
This change opens a socket pair and passes the second socket pair file descriptor down to the debugserver binary using a new option: "--fd=N" where N is the file descriptor. This file descriptor gets passed via posix_spawn() so that there is no need to do any bind/listen or bind/accept calls and eliminates the hanshake unix socket that is used to pass the result of the actual port that ends up being used so it can save time on launch as well as being faster.
This is currently only enabled on __APPLE__ builds. Other OSs should try modifying the #define from ProcessGDBRemote.cpp but the first person will need to port the --fd option over to lldb-server. Any OSs that enable USE_SOCKETPAIR_FOR_LOCAL_CONNECTION in their native builds can use the socket pair stuff. The #define is Apple only right now, but looks like:
#if defined (__APPLE__)
#define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1
#endif
<rdar://problem/27814880>
llvm-svn: 278524
Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.
This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.
Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham
llvm-svn: 278440
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
stopped due to a different reason - the interrupt request would remain queued and would
interfere with the following "continue". I also added a unit test for this case.
This reapplies r277156 and r277139.
llvm-svn: 278118
also take the opportunity to replace NULL with nullptr and add clang-format guards to prevent it
from messing up the nice table there.
llvm-svn: 278005
It only contained a reimplementation of std::to_string, which I have replaced with usages of
pre-existing llvm::to_string (also, injecting members into the std namespace is evil).
llvm-svn: 278000
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)
llvm-svn: 277154
Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.
The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout.
I have reused them and parse i386 files manually, and fill them in the
same struct.
Also added some error handling during parsing that checks if the
available bytes in the buffer are enough to fill the structures.
The i386 core file test case now passes.
For reference on the structures layout, I generally used the
source of binutils (bfd, readelf)
Bug: https://llvm.org/bugs/show_bug.cgi?id=26947
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22917
llvm-svn: 277140
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with
several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any
changes to how packet sending functions and threads interact was very difficult and error-prone.
This change does not add any functionality yet, it merely paves the way for future changes. In a
follow-up, I plan to add the ability to have multiple query packets in flight (i.e.,
request,request,response,response instead of the usual request,response sequences) and use that
to speed up qModuleInfo packet processing.
Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread,
and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and
blocks any other async threads from accessing the connection. Other threads create an instance of
the Lock object when they want to access the connection. This object, while in scope prevents the
continue from being send. Optionally, it can also interrupt the process to gain access to the
connection for async processing.
Most of the syncrhonization logic is encapsulated within these two classes. Some of it still
had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much
more manageable than before -- partly because of most of the work is done in the ContinueLock
class, and partly because I have factored out a lot of the packet processing code separate
functions (this also makes the functionality more easily testable). Most importantly, there is
none of syncrhonization code in the async thread users -- as far as they are concerned, they just
need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a
very thin wrapper around the NoLock version of the function, whereas previously it had over 100
lines of synchronization code). This will make my follow up changes there easy.
I have written a number of unit tests for the new code and I have ran the test suite on linux and
osx with no regressions.
Subscribers: tberghammer
Differential Revision: https://reviews.llvm.org/D22629
llvm-svn: 277139
Greg added in r272276 -- when working with a non-user-process mach-o
core file, force the permissions to readable + executable, else the
unwinder can stop backtracing early if it gets a pc value in a segment
that it thinks is non-executable.
<rdar://problem/27138456>
<rdar://problem/27462904>
llvm-svn: 277065
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
"Incorrect" file name seen on Android whene the main executable is
called "app_process32" (or 64) but the linker specifies the package
name (e.g. com.android.calculator2). Additionally it can be present
in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc
file system based on the base address sepcified by the linker in case
we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
Summary:
The binary layout of prstatus and prpsinfo was wrong.
Some of the member variables where not aligned properly
and others where with a wrong type (e.g. the time related
stuff in prstatus).
I used the structs defined in bfd in binutils to see what the layout
of the elf-core format in these section is.
(https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/hosts/x86-64linux.h;h=4e420a1f2081dd3b51f5d6b7a8e4093580f5cdb5;hb=master)
Note: those structures are only for x86 64 bit elf-core files
This shouldn't have any impact on the functionality, because
lldb actually uses only a few of the member variables of those structs
and they are with a correct type and alignment.
I found this while trying to add/fix the support for
i386 core files (https://llvm.org/bugs/show_bug.cgi?id=26947)
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22628
Author: Dimitar Vlahovski <dvlahovski@google.com>
llvm-svn: 276406
debugserver jGetSharedCacheInfo packet instead of reading
the dyld internal data structures directly. This code is
(currently) only used for ios native lldb's - I should really
move this ObjectFileMachO::GetProcessSharedCacheUUID method
somewhere else, it makes less and less sense being in the
file reader.
<rdar://problem/25251243>
llvm-svn: 276369
Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes
These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.
This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D22457
llvm-svn: 276288
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Windows live process and minidump implementations of lldb_private::Process (ProcessWindowsLive::GetMemoryRegionInfo and ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The existing Windows implementations didn’t fill in the start and end addresses within MemoryRegionInfo. This patch fixes that and adds support for the new mapped flag on MemoryRegionInfo that says whether a memory range is mapped into the process address space or not.
The behaviour of both live and core implementations should match the behaviour documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should match the behaviour of the qMemoryRegionInfo query documented in lldb-gdb-remote.txt.
Reviewers: clayborg, amccarth
Subscribers: amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D22352
llvm-svn: 275778
Summary:
This removes one level of indirection, which was just packing and repacking launch args into
different structures. NFC.
Reviewers: tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22357
llvm-svn: 275544
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
If LLDB reads some incorrect input form /proc/<pid>/maps then it
should report an error instead of assert-ing as we don't want to
crash in case of an incorrect maps file.
Differential revision: http://reviews.llvm.org/D22211
llvm-svn: 275060
On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping
and retrying should help us get more stable results.
llvm-svn: 274763
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo ®ion_info).
Reviewers: clayborg
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D21751
llvm-svn: 274741
Summary:
We are seeing infrequent failures to launch the inferior process on android. The failing call
seems to be execve(). This adds more logging to see the actual error reported by the call.
Reviewers: tberghammer
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D22039
llvm-svn: 274624
Summary:
This removes the last usage of Platform plugins in lldb-server -- it was used for launching child
processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always
running on the host).
Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as
a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and
architecture).
Reviewers: clayborg
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D20440
llvm-svn: 274125
Zachary Turner