This patch adds support for setting/clearing hardware watchpoints and breakpoints on AArch64 (Arm v8) 64-bit hardware.

http://reviews.llvm.org/D9706

llvm-svn: 237419

Remove handling of eStateStopped from NativeProcessLinux::Resume

Summary:
NPL::Resume attempted to handle eStateStopped as a resume action. However:
- GDBRemoteCommunicationServerLLGS (the only user

Remove handling of eStateStopped from NativeProcessLinux::Resume

Summary:
NPL::Resume attempted to handle eStateStopped as a resume action. However:
- GDBRemoteCommunicationServerLLGS (the only user of NPL) never sets this action
- it could set this action in response to a vCont:t packet, but LLDB never produces this packet
- gdb-remote protocol documentation says vCont:t packet is used only in non-stop mode, but LLDB
does not support non-stop mode
- even if LLDB supported non-stop mode, this implementation of eStateStopped does something
different from what the spec says it should (according to spec, it should stop the specified
thread, but this seems to want to stop all threads).

Given the facts above, I believe we should remove this unused and untested code, as it probably
doesn't even work and removing it makes the rest of the code noticably simpler.

Reviewers: ovyalov, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9657

llvm-svn: 237103

show more ...

[NativeProcessLinux] Remove event mutex and clean functions using it

Summary:
Since the former-TSC events are now processed synchronously, there is no need for to protect them
with a separate mutex

[NativeProcessLinux] Remove event mutex and clean functions using it

Summary:
Since the former-TSC events are now processed synchronously, there is no need for to protect them
with a separate mutex - all the actions are now guarded by the big m_threads_mutex.

With the mutex gone, the following functions, no longer have any purpose and were removed:
NotifyThreadCreate: replaced by direct calls to ThreadWasCreated
NotifyThreadStop: replaced by direct calls to ThreadDidStop
NotifyThreadDeath: folded into StopTrackingThread
ResetForExec: inlined as it consisted of a single line of code
RequestThreadResume(AsNeeded): replaced by direct calls to ResumeThread
StopThreads: removed, as it was never called

Test Plan: tests continue to pass

Reviewers: ovyalov, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9603

llvm-svn: 237101

show more ...

Get lldb-server building on android-9

Build lldb-server with an android-9 sysroot.

llvm-svn: 237078

[NativeProcessLinux] Remove double thread state accounting

Summary:
Now that all thread events are processed synchronously, there is no need to have separate records
of whether a thread is running.

[NativeProcessLinux] Remove double thread state accounting

Summary:
Now that all thread events are processed synchronously, there is no need to have separate records
of whether a thread is running. This changes the (ever-dwindling) remains of the TSC to use
NativeThreadLinux as the authoritative source of the state of threads. The rest of the
ThreadContext we need has been moved to a member of NTL.

Test Plan: ninja check-lldb continues to pass

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9562

llvm-svn: 236983

show more ...

[NativeProcessLinux] Remove the stop callback

Summary:
The stop callback is a remnant of the ThreadStateCoordinator. We don't need it now that TSC is
gone, as we know exactly which function to call

[NativeProcessLinux] Remove the stop callback

Summary:
The stop callback is a remnant of the ThreadStateCoordinator. We don't need it now that TSC is
gone, as we know exactly which function to call when threads stop. This also removes some
stop-related functions, which were just forwarding calls to one another.

Test Plan: ninja check-lldb continues to pass

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9531

llvm-svn: 236814

show more ...

[NativeProcessLinux] Remove logging and error callbacks

Summary:
These are remnants of the thread state coordinator, which are now unnecessary. I have basically
inlined the callbacks. No functional

[NativeProcessLinux] Remove logging and error callbacks

Summary:
These are remnants of the thread state coordinator, which are now unnecessary. I have basically
inlined the callbacks. No functional change.

Test Plan: Tests continue to pass.

Reviewers: chaoren, vharron

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9343

llvm-svn: 236707

show more ...

[LLDB][MIPS] Software single stepping
Patch by Jaydeep Patil

Reviewers: clayborg, jasonmolenda
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.or

[LLDB][MIPS] Software single stepping
Patch by Jaydeep Patil

Reviewers: clayborg, jasonmolenda
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9519

llvm-svn: 236696

show more ...

[NativeProcessLinux] Remove the post-stop lambda

Summary:
The lambda was always calling SetState(eStateStopped) with small variations, so I have inlined
the code. Given that we don't have the TSC an

[NativeProcessLinux] Remove the post-stop lambda

Summary:
The lambda was always calling SetState(eStateStopped) with small variations, so I have inlined
the code. Given that we don't have the TSC anymore, I believe we don't need to be so generic.

The only major change here is the way we choose a stop reason thread when we're interrupting a
program on client request. Previously, we were setting a null stop reason for all threads and
then fixing up the reason for one victim thread in the lambda. Now, I make sure the stop reason
is set for the victim thread correctly in the first place.

I also take the opportunity to rename CallAfter* functions into something more appropriate.

Test Plan: All tests continue to pass.

Reviewers: chaoren, vharron

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9321

llvm-svn: 236595

show more ...

[NativeProcessLinux] fold ThreadStateCoordinator into NPL

Summary:
Since all TSC operations are now executed synchronously, TSC has become a little more than a
messenger between different parts of N

[NativeProcessLinux] fold ThreadStateCoordinator into NPL

Summary:
Since all TSC operations are now executed synchronously, TSC has become a little more than a
messenger between different parts of NativeProcessLinux. Therefore, the reason for its existance
has disappeared.

This commit moves the contents of the TSC into the NPL class. This will enable us to remove all
the boilerplate code in NPL (as it stands now, this is most of the class), which I plan to do in
subsequent commits.

Unfortunately, this also means we will lose the unit tests for the TSC. However, since the size
of the TSC has diminished, the unit tests were not testing much at this point anyway, so it's not
a big loss.

No functional change.

Test Plan: All tests continue to pass.

Reviewers: vharron, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9296

llvm-svn: 236587

show more ...

Fix Android build.

llvm-svn: 236509

[NativeProcessLinux] Get rid of the thread state coordinator thread

Summary:
This change removes the thread state coordinator thread by making all the operations it was
performing synchronous. In or

[NativeProcessLinux] Get rid of the thread state coordinator thread

Summary:
This change removes the thread state coordinator thread by making all the operations it was
performing synchronous. In order to prevent deadlock, NativeProcessLinux must now always call
m_monitor->DoOperation with the m_threads_mutex released. This is needed because HandleWait
callbacks lock the mutex (which means the monitor thread will block waiting on whoever holds the
lock). If the other thread now requests a monitor operation, it will wait for the monitor thread
do process it, creating a deadlock.

To preserve this invariant I have introduced two new Monitor commands: "begin operation block"
and "end operation block". They begin command blocks the monitor from processing waitpid
events until the corresponding end command, thereby assuring the monitor does not attempt to
acquire the mutex.

Test Plan: Run the test suite locally, verify no tests fail.

Reviewers: vharron, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9227

llvm-svn: 236501

show more ...

Remove trap code from disassembly.

Summary:
NativeProcessProtocol uses ReadMemory internally for setting/checking
breakpoints but also for generic memory reads (Handle_m), this change adds a
ReadMem

Remove trap code from disassembly.

Summary:
NativeProcessProtocol uses ReadMemory internally for setting/checking
breakpoints but also for generic memory reads (Handle_m), this change adds a
ReadMemoryWithoutTrap for that purpose. Also fixes a bunch of misuses of addr_t
as size/length.

Test Plan: `disassemble` no longer shows the trap code.

Reviewers: jingham, vharron, clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9330

llvm-svn: 236132

show more ...

[NativeProcessLinux] Add back synchronisation of thread create events

Summary:
Without the synchronisation between the two thread creation events the following case could
happen:
- threads A and B a

[NativeProcessLinux] Add back synchronisation of thread create events

Summary:
Without the synchronisation between the two thread creation events the following case could
happen:
- threads A and B are running. A hits a breakpoint. We note that we want to stop B.
- before we could stop it, B creates a new thread C, we get the stop notification for B, but we
don't record C's existence yet.
- we resume B
- before we get the C notification, B stops again (e.g. hits a breakpoint, gets our SIGSTOP,
etc.)
- we see all known threads have stopped, and we notify LLDB
- C notification comes, we note it's existence and resume it
=> we have an inconsistent state (LLDB thinks we've stopped, but C is running)

I resolve this by doing a blocking wait for for the C notification when we get the creation
notification on the parent (B) thread. This way the two events are synchronised, but we don't
need to introduce the intermediate "launching" state which would complicate handling of thread
states as all code would need to be aware of the third possible state.

Test Plan:
This is an obscure corner case, which I had not observed in practise, so I have no
test for it. I have tested that this commit does not regress in existing tests though.

Reviewers: chaoren, vharron

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9217

llvm-svn: 235969

show more ...

Fix register read callback in linux-arm single stepping

The previous read callback always read the value of the register what
caused problems when the emulator wrote some value into a register and
t

Fix register read callback in linux-arm single stepping

The previous read callback always read the value of the register what
caused problems when the emulator wrote some value into a register and
then expected to read the same value back. This CL add a register value
cache into the callbacks to return the correct value after a register
write also.

Test Plan: Stepping over BL/BLX instruction works on android-arm if the instruction set isn't change (other, unrelated patch will come for the case when we move to an other instruction set)

Reviewers: omjavaid, sas, clayborg

Reviewed By: clayborg

Subscribers: labath, tberghammer, rengolin, aemerson, lldb-commits

Differential Revision: http://reviews.llvm.org/D9187

From: Tamas Berghammer <[email protected]>
llvm-svn: 235852

show more ...

Fix TestFdLeak on Linux.

Summary:
LLGS leaks pipes (when launched by lldb), sockets (when launched by platform),
and/or log file to the inferior. This should prevent all possible leaks.

Reviewers:

Fix TestFdLeak on Linux.

Summary:
LLGS leaks pipes (when launched by lldb), sockets (when launched by platform),
and/or log file to the inferior. This should prevent all possible leaks.

Reviewers: vharron, clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9211

llvm-svn: 235615

show more ...

[NativeProcessLinux] Fix race condition during inferior thread creation

The following situation occured if we were stopping a process (due to breakpoint, watchpoint, ...
hit) while a new thread was

[NativeProcessLinux] Fix race condition during inferior thread creation

The following situation occured if we were stopping a process (due to breakpoint, watchpoint, ...
hit) while a new thread was being created.
- process has two threads: A and B.
- thread A hits a breakpoint: we send a STOP signal to thread B and register a callback with
ThreadStateCoordinator to send a stop notification after the thread stops.
- thread B stops, but not due to the SIGSTOP, but on a thread creation event (of a new thread C).
We are unaware of our desire to stop, so we queue ThreadStopped and RequestResume operations
with TSC, so the thread can continue running.
- TSC receives the ThreadStopped event, sees that all threads are stopped and fires the delayed
stop notification.
- immediately after that TSC gets the RequestResume operation, so it resumes the thread.

At this point the state is inconsistent because LLDB thinks the process is stopped and will start
issuing commands to it, but one of the threads is in fact running. Things eventually break.

I address this problem by omitting the two TSC events altogether and Resuming the thread B
directly. This way the short stop is invisible to the TSC and the delayed notification will not
fire. We will fire the notification when we actually process the SIGSTOP on thread B.

When we get the initial SIGSTOP for thread C, we also resume the thread and send a
ThreadWasCreated message (is_stopped = false) to the TSC. This way, the TSC can stop the thread
on its own and handle the stop event later. This way the state of the new thread is correctly
handled as well (thanks Chaoren for the idea).

This patch also removes the synchronisation between the thread creation notifications on threads
B and C. The need for this synchronisation is unclear (the comments seem to hint that the new
thread is "fully created" only after we process both events, but I have noticed no regressions in
treating it as "created" even after just processing the initial C event), but it is a source for
many kinds of obscure races, since it introduces a new thread state "Launching" and the rest of
the code does not handle this state at all (what happens if we get a resume request from LLDB
while this thread is launching? what happens if we get a stop request? etc.).

This fixes the "spurious $O packet" problem in TestPrintStackTraces.py. However, the test remains
disabled on i386 due to the VDSO issue.

Test Plan:
TestPrintStackTraces works on x86_64. No regressions in the rest of the test suite.

Reviewers: vharron, chaoren

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9145

llvm-svn: 235579

show more ...

[LLDB][MIPS] Add MIPS32 and MIPS64 core revisions
Patch by Jaydeep Patil

Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.

DYLDR

[LLDB][MIPS] Add MIPS32 and MIPS64 core revisions
Patch by Jaydeep Patil

Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.

DYLDRendezvous.cpp:
On Linux link map struct does not contain extra load offset field.

Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9190

llvm-svn: 235574

show more ...

Fix signle stepping on arm when multiple thread is involved

On linux-arm we use software single stepping where setting the new
breakpoint is only possible while the process is in stopped state.
This

Fix signle stepping on arm when multiple thread is involved

On linux-arm we use software single stepping where setting the new
breakpoint is only possible while the process is in stopped state.
This CL moves the setup code for single stepping form the SigneStep
operation into the Resum method to avoid an error when the process
already started when we want to step one of the thread.

Differential revision: http://reviews.llvm.org/D9108

llvm-svn: 235494

show more ...

NativeProcessLinux: Merge operation and monitor threads

Summary:
This commit moves the functionality of the operation thread into the new monitor thread. This is
required to avoid a kernel race betw

NativeProcessLinux: Merge operation and monitor threads

Summary:
This commit moves the functionality of the operation thread into the new monitor thread. This is
required to avoid a kernel race between the two threads and I believe it actually makes the code
cleaner.

Test Plan: Ran the test suite a couple of times, no regressions.

Reviewers: ovyalov, tberghammer, vharron

Subscribers: tberghammer, lldb-commits

Differential Revision: http://reviews.llvm.org/D9080

llvm-svn: 235304

show more ...

Auto advance pc for signle stepping on arm when emulation failes

The arm instruction emulation handles only some of the opcode (including
all of them modifying the PC). For the rest of the instructi

Auto advance pc for signle stepping on arm when emulation failes

The arm instruction emulation handles only some of the opcode (including
all of them modifying the PC). For the rest of the instructions we can
advance the PC by the size of the instruction as they don't modify the
PC on any other way.

Differential revision: http://reviews.llvm.org/D9076

llvm-svn: 235292

show more ...

Fix LLDB ARM GCC4.7 broken build

llvm-svn: 235280

Use non-blocking waitpid in NativeProcessLinux

Summary:
This is the first phase of the merging of Monitor and Operation threads in NativeProcessLinux
(which is necessary since the two threads race i

Use non-blocking waitpid in NativeProcessLinux

Summary:
This is the first phase of the merging of Monitor and Operation threads in NativeProcessLinux
(which is necessary since the two threads race inside Linux kernel). Here, I reimplement the
Monitor thread do use non-blocking waitpid calls, which enables later addition of code from the
operation thread.

Test Plan: Ran the test suite a couple of times, no regressions detected.

Reviewers: vharron, ovyalov, tberghammer

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9048

llvm-svn: 235193

show more ...

Add single stepping logic for linux arm

Linux arm don't support hardware stepping (neither mismatch
breakpoints). This patch implement signle stepping with doing a software
emulation of the next ins

Add single stepping logic for linux arm

Linux arm don't support hardware stepping (neither mismatch
breakpoints). This patch implement signle stepping with doing a software
emulation of the next instruction and then setting a temporary
breakpoint at the address where the thread will stop next.

Differential revision: http://reviews.llvm.org/D8976

llvm-svn: 234987

show more ...

Fix breakpoint trap opcode detection for arm linux

llvm-svn: 234986