In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality. Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area. Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.
Differential Revision: https://reviews.llvm.org/D30560
llvm-svn: 296910
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Summary:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?),
which can't access the non-const function.
Reviewers: labath, eugene
Reviewed By: labath, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30515
Author: Jason Majors <jmajors@google.com>
llvm-svn: 296868
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
MSVC (at least the version I am using) does not want to implicitly
capture a const bool variable. Move it into the lambda, as it is not
used outside anyway.
llvm-svn: 296738
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
llvm-svn: 296329
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.
Reviewers: jmajors, labath
Subscribers: danalbert, srhines, emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 296101
acquired only after checking if the ivar shared pointer was already
filled in. But when I assign an UnwindPlan object to the shared
pointer, I assign an empty object and then fill it in. That leaves
a window where another thread could get the shared pointer to the
empty (but quickly being-filled-in) object and lead to a crash.
Also two changes from Greg for correctness on the TestMultipleDebuggers
test case.
<rdar://problem/30564102>
llvm-svn: 296084
Summary:
NetBSD 7.99.62 introduced Debug Registers interface similar to the FreeBSD one.
This interface will land NetBSD-8.0.
Introduce support for this interface in Register Context NetBSD x86_64 unconditionally as older versions of NetBSD will not be supported.
This change allows to reduce diff with other ports and remove local copy of the RegisterInfos_x86_64.h content.
NetBSD Register Context for 32-bit x86 support will be added later.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30287
llvm-svn: 296071
Summary:
NetBSD 8.0 will ship with accept4(2) in libc wrapping paccept(2).
This change reduces needless difference with other platforms.
Older versions of NetBSD will not be supported.
No functional change.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, emaste, labath, clayborg
Reviewed By: emaste, labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30288
llvm-svn: 296070
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
Summary:
When lldb-server is started with the -P <port> or -m/-M <min/max port> options to specify which ports are available for remote connections the child debug server is told what port it should listen on. In those cases lldb-server needs to wait for the child to report it’s port number as otherwise it can tell the lldb client that the child is up and listening before it is actually listening on that port. lldb-server already waits in the cases where a port wasn’t specified by waiting until the child reports the port it is using. It was skipping this synchronisation step when passed a port numbers as it knew what the port would be however it does need to ensure the child process has had time to open that port and waiting until the child reports the port number makes sure this has happened.
This patch just removes the one case where a child was spawned and lldb-server did not wait for it to report it’s port number before telling the client lldb process the child is ready to connect to.
This issue was discussed on lldb-dev in a thread here:
http://lists.llvm.org/pipermail/lldb-dev/2017-February/012002.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30255
llvm-svn: 295947
- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block
<rdar://problem/30644888>
llvm-svn: 295907
Summary:
The main difference here is that in the WINLOG macros you can specify
log categories per call, whereas here you have to go the usual lldb
route of getting a Log* variable first. While this means you have to
write at least two statements, it usually means that each statement will
fit on a single line, whereas fitting the WINLOG invocation on a single
line was almost impossible. So the total size of code does not increase
even in functions with a single log statement, and functions with more
logging get shorter.
The downside here is reduced flexibility in specifying the log
categories, which a couple of functions used quite heavily (e.g.
RefreshStateAfterStop). For these I chose a single category used most
prominently and put everything into that, although a solution with
multiple log variables is definitely possible.
Reviewers: zturner, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30172
llvm-svn: 295822
Summary:
The code was attempting to copy the shared pointer member in order to
guarantee atomicity, but this is not enough. Instead, protect the
pointer with a proper read-write mutex.
This bug was present here for a long time, but my recent refactors must
have altered the timings slightly, such that now this fails fairly often
when running the tests: the test runner runs the "log disable" command
just as the thread monitoring the lldb-server child is about to report
that the server has exited.
I add a test case for this. It's not possible to reproduce the race
deterministically in normal circumstances, but I have verified that
before the fix, the test failed when run under tsan, and was running
fine afterwards.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30168
llvm-svn: 295712
Summary:
I originally set out to move the NameMatches closer to the relevant
function and add some unit tests. However, in the process I've found a
couple of bugs in the implementation:
- the early exits where not always correct:
- (test==pattern) does not mean the match will always suceed because
of regular expressions
- pattern.empty() does not mean the match will fail because the "" is
a valid prefix of any string
So I cleaned up those and added some tests. The only tricky part here
was that regcomp() implementation on darwin did not recognise the empty
string as a regular expression and returned an REG_EMPTY error instead.
The simples fix here seemed to be to replace the empty expression with
an equivalent non-empty one.
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30094
llvm-svn: 295651
Summary:
There have been a few new values added to a few LLVM enums
this change makes sure that LLDB code handles them correctly.
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30005
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 295445
Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
llvm::StringLiteral: fix gcc build
llvm-svn: 295442
In the case we are stepping over the thread creation instruction, we
will end up calling Thread::SingleStep back-to-back twice (because of
the intermediate PTRACE_EVENT_CLONE stop). This will cause the cpu mask
to be set inappropriately (because the old SingleStepCheck object will
be destroyed after we create the new one), and the single-step will
fail.
Before the refactor the code was still incorrect in this case, but in a
different way (the thread was left with the incorrect mask after the
stepping was complete), so this was not easy to spot.
This fixes TestCreateDuringInstructionStep on the affected devices.
llvm-svn: 295440
While refactoring the code in r293046 I made a very basic error -
relying on destructor side-effects of a copyable object. Fix that and
make the object non-copyable.
This fixes the tests on the platforms that need this workaround, but
unfortunately we don't have a way to make a more platform-agnostic test
right now.
llvm-svn: 295345
TSan now has the ability to report races on "external" object, i.e. any library class/object that has read-shared write-exclusive threading semantics. The detection and reporting work almost out of the box, but TSan can now provide the type of the object (as a string). This patch implements this into LLDB.
Differential Revision: https://reviews.llvm.org/D30024
llvm-svn: 295342
effects was passed as an expression to assert() calls. If lldb is
built without asserts, the expression was eliminated and we lost
the side effects -- these methods stopped working.
<rdar://problem/30342959>
llvm-svn: 295271
Summary:
We currently have two log channel registration mechanisms. One uses a
set of function pointers and the other one is based on the
PluginManager.
The PluginManager dependency is unfortunate, as logging
is also used in lldb-server, and the PluginManager pulls in a lot of
classes which are not used in lldb-server.
Both approach have the problem that they leave too much to do for the
user, and so the individual log channels end up reimplementing command
line argument parsing, category listing, etc.
Here, I replace the PluginManager-based approach with a one. The new API
is more declarative, so the user only needs to specify the list of list
of channels, their descriptions, etc., and all the common tasks like
enabling/disabling categories are hadled by common code. I migrate the
LogChannelDWARF (only user of the PluginManager method) to the new API.
In the follow-up commits I'll replace the other channels with something
similar.
Reviewers: clayborg, zturner, beanz
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D29895
llvm-svn: 295190
Summary:
It turns out listing each library twice is not enough to resolve all
references in a debug build on linux - a number of executables fails to
link with random symbols missing. Increasing the number to three seems
to be enough. The choice of lldbCore to set the multiplicity on is
somewhat arbitrary, but it seems fitting, as it is the biggest layering
transgressor.
Reviewers: beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D29888
llvm-svn: 295189
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
Summary:
We've had two ways to print a "debug" log message.
- Log::GetDebug() was testing a Stream flag which was never set.
- Log::Debug() was checking for the presence of "log enable --debug"
flag.
Given that these two were used very rarely and we already have a
different way to specify "I want a more verbose log", I propose to remove
these two functions and migrate the callers to LLDB_LOGV. This commit
does that.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29823
llvm-svn: 294939
and use it in the appropriate log statements.
Formatting of chrono types in log messages was very clunky. This should
make it much nicer to use and give better output. For details of the
formatting options see the chrono formatter in llvm.
llvm-svn: 294738
Summary:
This converts LLDB's logging to use llvm streams instead of
lldb_private::Stream and friends. The changes are mostly
straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream.
The part worth calling out is the rewrite of the StreamCallback class.
Previously this class contained a per-thread buffer of data written. I
assume this had something to do with it trying to make sure each log
line is delivered as a single event, instead of multiple (possibly
interleaved) events. However, this is no longer relevant as the Log
class already writes things to a temporary buffer and then delivers the
message as a single "write", so I have just removed the code in
question.
Reviewers: zturner, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29615
llvm-svn: 294736
After many expressions are evaluated we were spending time looking for open blocks on memory in the one or more AllocatedBlock objects and it would slow down expression evaluation.
I implemented a fixed size blocks implementation that maintains a sorted free list to fix the issue.
<rdar://problem/17962974>
llvm-svn: 294600
CommandObjectVersion.cpp calls lldb_private::GetVersion (present in lldbBase).
This should fix the unittest link on windows. I am not sure why is this not
present on other platforms -- my guess is that there lldbBase is included in
the link through some other dependency chain.
llvm-svn: 294549
Summary:
This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool.
This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too.
Help testing would be greatly appreciated.
Reviewers: labath, zturner
Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits
Differential Revision: https://reviews.llvm.org/D29352
llvm-svn: 294515
Inspired by r294145 for NetBSD, this reduces diffs between the FreeBSD
and Linux/NetBSD Platform implementations. Further diff reduction will
occur once FreeBSD switches to using the remote process plugin.
Differential Revision: https://reviews.llvm.org/D29667
llvm-svn: 294340
Instead just rely on LLDB_LOG().
This is part of an effort to sort out dependency hell in LLDB.
Error is in Utility, but Log is in Core. Core can depend on
Utility, but not vice versa. So this patch moves the knowledge
about how to log Errors from the Error class to the Log file.
Differential Revision: https://reviews.llvm.org/D29514
llvm-svn: 294210
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
Summary:
Update the code to the new world code.
These changes are needed for remote process plugin.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, clayborg, joerg, labath
Reviewed By: clayborg, labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29266
llvm-svn: 294145
don't create a platform.linux setting category, as it contains no
actual settings, and I don't forsee adding any soon. Also remove some
unused includes while I'm in there.
llvm-svn: 294114
Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.
I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29510
llvm-svn: 294113
Summary:
- GetFileWithUUID: All platforms except PlatformDarwin had this.
However, I see no reason why this code would not apply there as well.
- GetProcessInfo, FindProcesses: The implementation was the same in all classes.
- GetFullNameForDylib: This code should apply to all non-darwin
platforms. I've kept the PlatformDarwin override as the situation is
different there.
Reviewers: clayborg, krytarowski, emaste
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29496
llvm-svn: 294019
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
Summary:
various platforms very using nearly identical code for this method. As far as I
can tell there was nothing platform-specific about the differences, but rather
it looked like it was caused by tiny tweaks being made to individual copies
without affecting the overall functionality. I have taken the superset of all
these tweaks and put it into one method in the base class (incidentaly, nobody
was using the base class implementation of the method, as all classes were
overriding it). From the darwin class I took the slightly improved error
reporting (checking whether the file is readable) and the
ResolveExecutableInBundle call (which has no effect elsewhere as the function
is already a no-op on non-darwin platforms). From the linux class I took the
set-the-triple-vendor-to-host-if-unspecified tweak (present in PlatformKalimba
as well).
PlatformWindows has an identical copy as well. We could resolve that by pushing
this code further down into Platform class, that that would require pushing the
m_remote_platform_sp member as well, which seems like a bad design choice.
Reviewers: clayborg, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29406
llvm-svn: 293910
print the path being requested.
Change the GetInfoItemByPathAsString docuemtnation in
the .i file to use docstring instead of autodoc so
the function signature is included in the python
help.
<rdar://problem/29999567>
llvm-svn: 293858
Summary:
Use ProcessLauncherPosixFork in Linux and NetBSD.
Changes to ProcessLauncherLinux:
- Limit personality.h and ASLR code to Linux.
- Reuse portable ptrace(2) PT_TRACE_ME operation available on Linux and BSDs.
- Limit ETXTBSY error path from execve(2) to Linux.
- In LaunchProcess declaration change virtual to override.
This code should be readily available for FreeBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, clayborg, labath, emaste
Reviewed By: labath
Subscribers: danalbert, srhines, mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29347
llvm-svn: 293768
Summary:
Problem:
There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx -
that could be bigger than 64K and therefore do not fit in 16 bits reserved for
them in the header. If this happens, pretty often there is a special section at
index 0 which contains their real values for these fields in the section header
in the fields sh_info, sh_size, and sh_link respectively.
Fix:
- Rename original fields in the header declaration. We want to have them around
just in case.
- Reintroduce these fields as 32-bit members at the end of the header. By default
they are initialized from the header in Parse() method.
- In Parse(), detect the situation when the header might have been extended into
section info #0 and try to read it from the same data source.
- ObjectFileELF::GetModuleSpecifications accesses some of these fields but the
original parse uses too small data source. Re-parse the header if necessary
using bigger data source.
- ProcessElfCore::CreateInstance uses header with potentially sentinel values,
but it does not access these fields, so a comment here is enough.
Reviewers: labath
Reviewed By: labath
Subscribers: davidb, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29095
Author: Eugene Birukov <eugenebi@hotmail.com>
llvm-svn: 293714
Summary:
This patch does two things. First it updates all the ABI plugins with accurate dependencies, and second it adds a tracking mechanism for add_lldb_library to denote plugin libraries, allowing us to build up a list of all the configured plugins.
This list of generated plugins will be used during generating liblldb so that we can link all the plugins into the library.
If this patch looks good I will update all the other plugins in subsequent patches.
Reviewers: labath, zturner
Subscribers: nemanjai, mgorny, lldb-commits, jgosnell
Differential Revision: https://reviews.llvm.org/D29348
llvm-svn: 293696
Summary:
This patch adds accurate dependency specifications to the mail LLDB libraries and tools.
In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way.
For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up.
Reviewers: labath, zturner
Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell
Differential Revision: https://reviews.llvm.org/D29333
llvm-svn: 293686
Summary:
To retrieve the native thread ID there must be called _lwp_self().
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, clayborg, emaste, labath
Reviewed By: joerg, clayborg, labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29264
llvm-svn: 293625
Summary:
Remove dependency on the proc (/proc) filesystem, which is optional.
KERN_PROC_PATHNAME is available in NetBSD-current and will land NetBSD 8.0.
Older stable versions of NetBSD will not be supported.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, labath, clayborg
Reviewed By: clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29089
llvm-svn: 293392
Summary:
Real-Time Signals are available in NetBSD-current and will land NetBSD 8.0.
Older stable versions of NetBSD will not be supported.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, clayborg, emaste
Reviewed By: labath, clayborg, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29091
llvm-svn: 293391
header line, backtrace output) was to remove the current pc value
from frames where we have source level information. We've been
discussing this for the past week and based on input from a group
of low level users, I believe this is the wrong default behavior
for the command line lldb tool.
lldb's backtrace will include the pc value for all stack frames
regardless of whether they have source level debug information or
not.
A related part of r286288 removes the byte offset printing for
functions with source level information (e.g. "main + 22 sourcefile.c:10"
is printed as "main sourcefile.c:10"). I don't see a compelling
case for changing this part of 286288 so I'm leaving that as-is
(in addition to the rest of 286288 which is clearly better than
the previous output style).
<rdar://problem/30083904>
llvm-svn: 293366
This moves the accept hack from the android toolchain file into
LLDBConfig.cmake. This allows successful lldb android compilation
without relying on our custom toolchain file.
llvm-svn: 293281
The main motivation for me doing this is being able to build an arm
android lldb-server against api level 9 headers, but it seems like a
good cleanup nonetheless.
The entirety of the cpu_set_t dance now resides in SingleStepCheck.cpp,
which is only built on arm64.
llvm-svn: 293046
Summary: This commit adds an option to set PC to the entry point of the file loaded using "target module load" command. In D28804, Greg asked me to separate this part under a different option.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D28944
llvm-svn: 292989
Summary: LLDB was using packet size advertised by the target as the max memory size to write in one go. It is wrong because packets have other overhead apart from memory payload. Also memory transferred through 'm' and 'M' packets needs 2 bytes in packet to transfer 1 of memory.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D28808
llvm-svn: 292987
It turns out things are not as simple as I hoped. sys/personality.h
exists on all androids but it does not define the required symbols on
all platform levels.
Add a compile check for platform level to compile against both new and
old android headers.
llvm-svn: 292939
Implementation of software single step for FreeBSD on ARM. The code is
largely based on the Linux implementation of the same functionality.
Patch by Dmitry Mikulin!
Differential Revision: https://reviews.llvm.org/D25756
llvm-svn: 292937
On android API level 9 the header does not get included transitively.
Include it directly.
As far as I can see, all non-windows platforms should have this header.
If that turns out to be incorrect, we can add some ifdefs around that.
llvm-svn: 292931
Summary:
getcwd() is not available (well.. um.. deprecated?) on windows, and the way
PosixApi.h is providing it causes strange compile errors when it's included in
the wrong order. The best way to avoid that is to just not use chdir.
This replaces all uses of getcwd in generic code. There are still a couple of
more uses, but these are in platform-specific code.
chdir() is causing a similar problem, but for that there is no llvm equivalent
for that (yet).
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D28858
llvm-svn: 292795
Summary:
The server was no longer sending the thread PCs the way the client
expected them.
I changed the server to send them back as a threadstop info field,
similar to the Apple version of the server.
I also changed the client to look for them there, before querying the
server.
I added a test to ensure the server doesn't stop sending them.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D28880
Author: Jason Majors
llvm-svn: 292611
For bare-metal targets, lldb was missing a command like 'load' in gdb
which can be used to create executable image on the target. This was
discussed in
http://lists.llvm.org/pipermail/lldb-dev/2016-December/011752.html
This commits adds an option to "target module load" command to provide
that functionality. It does not set the PC to entry address which will
be done separately.
Reviewed in https://reviews.llvm.org/D28804
llvm-svn: 292499
Use the LLDB_LOG macro instead of the more verbose if(log) ... syntax.
I have also consolidated the log channels (everything now goes to the posix
channel, instead of a mixture of posix and lldb), and cleaned up some of the
more convoluted log statements.
llvm-svn: 292489
starts up, we need to clear the target's image list and only add
the binaries into the target that are actually present in this
process run.
<rdar://problem/29857613>
llvm-svn: 292454
Zachary Turner