Refactor Unix signals.

Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platf

Refactor Unix signals.

Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.

Reviewers: ovyalov, clayborg

Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits

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

llvm-svn: 242101

show more ...

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.

After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.

This is a resubmit of r241672, after it was reverted due to build failueres on non-linux
platforms.

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 241796

show more ...

Revert r241672, which breaks the OS X build by introducing a dependency on
platform-specific symbols that are not implemented on OS X.

The build error that caused this is

Undefined symbols for arch

Revert r241672, which breaks the OS X build by introducing a dependency on
platform-specific symbols that are not implemented on OS X.

The build error that caused this is

Undefined symbols for architecture x86_64:
"lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
"lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

llvm-svn: 241688

show more ...

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.

After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 241672

show more ...

Fix cmake build after recent JSON changes

I have moved StringExtractor.h into the include/ folder so that it can be properly included by
everyone.

llvm-svn: 241572

Fix aarch64 breakpoint PC offset

llvm-svn: 241347

Fix qMemoryRegionInfo packet to return current value for address after the last memory region

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

llvm-svn: 241333

[NativeProcessLinux] Refactor PtraceWrapper

Summary:
This changes PtraceWrapper to return an Error, while the actual result is in an pointer parameter
(instead of the other way around). Also made a

[NativeProcessLinux] Refactor PtraceWrapper

Summary:
This changes PtraceWrapper to return an Error, while the actual result is in an pointer parameter
(instead of the other way around). Also made a couple of PtraceWrapper arguments default to zero.
This arrangement makes a lot of the code much simpler.

Test Plan: Tests pass on linux. It compiles on android arm64/mips64.

Reviewers: chaoren, mohit.bhakkad

Subscribers: tberghammer, aemerson, lldb-commits

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

llvm-svn: 241079

show more ...

[NativeProcessLinux] Use lambdas in DoOperation calls

Summary:
This removes a lot of boilerplate, which was needed to execute monitor operations. Previously one
needed do declare a separate class fo

[NativeProcessLinux] Use lambdas in DoOperation calls

Summary:
This removes a lot of boilerplate, which was needed to execute monitor operations. Previously one
needed do declare a separate class for each operation which would manually capture all needed
arguments, which was very verbose. In addition to less code, I believe this also makes the code
more readable, since now the implementation of the operation can be physically closer to the code
that invokes it.

Test Plan: Code compiles on x86, arm and mips, tests pass on x86 linux.

Reviewers: tberghammer, chaoren

Subscribers: aemerson, lldb-commits

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

llvm-svn: 240772

show more ...

[LLDB][MIPS] MIPS32 branch emulation and single-stepping

SUMMARY:
This patch implements
1. Emulation of MIPS32 branch instructions
2. Enable single-stepping for MIPS32 instru

[LLDB][MIPS] MIPS32 branch emulation and single-stepping

SUMMARY:
This patch implements
1. Emulation of MIPS32 branch instructions
2. Enable single-stepping for MIPS32 instructions
3. Correction in emulation of MIPS64 branch instructions with delay slot
4. Adjust breakpoint address when breakpoint is hit in a forbidden slot of compact branch instruction

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

llvm-svn: 240373

show more ...

Fetch object file load address if it isn't specified by the linker

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

llvm-svn: 240052

[LLDB][MIPS] Hardware Watchpoints for MIPS

Reviewers: clayborg, jingham.
Subscribers: jaydeep, bhushan, dsanders, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9142

llvm-svn:

[LLDB][MIPS] Hardware Watchpoints for MIPS

Reviewers: clayborg, jingham.
Subscribers: jaydeep, bhushan, dsanders, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9142

llvm-svn: 239991

show more ...

[NativeProcessLinux] Use fast memory reads, if the system supports it

Summary:
Memory reads using the ptrace API need to be executed on a designated thread
and in 4-byte increments. The process_vm_r

[NativeProcessLinux] Use fast memory reads, if the system supports it

Summary:
Memory reads using the ptrace API need to be executed on a designated thread
and in 4-byte increments. The process_vm_read syscall has no such requirements
and it is about 50 times faster. This patch makes lldb-server use the faster
API if the target kernel supports it. Kernel support for this feature is
determined at runtime. Using process_vm_writev in the same manner is more
complicated since this syscall (unlike ptrace) respects page protection settings
and so it cannot be used to set a breakpoint, since code pages are typically
read-only. However, memory writes are not currently a performance bottleneck as
they happen much more rarely.

Test Plan: all tests continue to pass

Reviewers: ovyalov, vharron

Subscribers: tberghammer, lldb-commits

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

llvm-svn: 239924

show more ...

[MIPS][lldb-server] Add 32-bit register context and read/write FP registers on mips64

- Added support for read/write FP registers in FR1 mode.
- Added 32 bit register context for mips32.

Re

[MIPS][lldb-server] Add 32-bit register context and read/write FP registers on mips64

- Added support for read/write FP registers in FR1 mode.
- Added 32 bit register context for mips32.

Reviewers: clayborg, tberghammer, jaydeep
Subscribers: emaste, nitesh.jain, bhushan, mohit.bhakkad, lldb-commits
Differential Revision: http://reviews.llvm.org/D10029

llvm-svn: 238914

show more ...

Refactor many file functions to use FileSpec over strings.

Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationC

Refactor many file functions to use FileSpec over strings.

Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.

Reviewers: ovyalov, zturner, vharron, clayborg

Reviewed By: clayborg

Subscribers: tberghammer, emaste, lldb-commits

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

llvm-svn: 238604

show more ...

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore,

Don't #include "lldb-python.h" from anywhere.

Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.

None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.

llvm-svn: 238581

show more ...

[NativeProcessLinux] clean up #includes

llvm-svn: 238551

Report inferior SIGSEGV as a signal instead of an exception on linux

Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to

Report inferior SIGSEGV as a signal instead of an exception on linux

Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.

This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.

I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).

Test Plan: All tests pass on linux and osx.

Reviewers: ovyalov, clayborg, emaste

Subscribers: emaste, lldb-commits

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

llvm-svn: 238549

show more ...

[NativeProcessLinux] Support inferiors which change their process group

Summary:
Previously, we wait()ed for events from the inferiors process group. This is resulted in a
failure if the inferior ch

[NativeProcessLinux] Support inferiors which change their process group

Summary:
Previously, we wait()ed for events from the inferiors process group. This is resulted in a
failure if the inferior changed its process group in the middle of execution. To avoid this, I
pass -1 to the wait() call. The flag __WNOTHREAD makes sure we don't actually wait for events
from any process, but only the processes(threads) which are our children (or traced by us). Since
this happens on the monitor thread, which is dedicated to monitoring a single inferior, we will
be getting events only from this inferior.

Test Plan: All tests pass on linux. I have added a test to check the new functionality.

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 238405

show more ...

Move register reading form NativeProcessLinux to NativeRegisterContextLinux*

This change reorganize the register read/write code inside lldb-server on Linux
with moving the architecture independent

Move register reading form NativeProcessLinux to NativeRegisterContextLinux*

This change reorganize the register read/write code inside lldb-server on Linux
with moving the architecture independent code into a new class called
NativeRegisterContextLinux and all of the architecture dependent code into the
appropriate NativeRegisterContextLinux_* class. As part of it the compilation of
the architecture specific register contexts are only compiled on the specific
architecture because they can't be used in other cases.

The purpose of this change is to remove a lot of duplicated code from the different
register contexts and to remove the architecture dependent codes from the global
NativeProcessLinux class.

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

llvm-svn: 238196

show more ...

[NativeProcessLinux] Fix handling of SIGSTOP

Summary:
Previously, NPL tried to reinject SIGSTOP into the inferior in an attempt to get the process to
start in the group-stop state. This was:
a) wron

[NativeProcessLinux] Fix handling of SIGSTOP

Summary:
Previously, NPL tried to reinject SIGSTOP into the inferior in an attempt to get the process to
start in the group-stop state. This was:
a) wrong (reinjection should be controlled by "process handle" lldb setting)
b) racy (it should use Resume for transparent resuming instead of RequestResume)
c) broken (llgs crashed on inferior SIGSTOP)

With this change, SIGSTOP is handled just like any other signal delivered to the inferior: we
stop all threads and report signal reception to lldb. SIGSTOP reinjection does not behave the
same way as it would outside the debugger, but simulating this is a hard problem and is not
normally necessary.

Test Plan: I have added a test which verifies we get SIGSTOP reports and we do not crash.

Reviewers: ovyalov, chaoren

Subscribers: lldb-commits

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

llvm-svn: 237880

show more ...

Fixed arm64 build error

llvm-svn: 237493

[NativeProcessLinux] Fix removal of temporary breakpoints

Summary:
There was an issue in NPL, where we attempted removal of temporary breakpoints (used to implement
software single stepping), while

[NativeProcessLinux] Fix removal of temporary breakpoints

Summary:
There was an issue in NPL, where we attempted removal of temporary breakpoints (used to implement
software single stepping), while some threads of the process were running. This is a problem
since we currently always use the main thread's ID in the removal ptrace call. Therefore, if the
main thread was still running, the ptrace call would fail, and the software breakpoint would
remain, causing all kinds of problems. This change removes the breakpoints after all threads have
stopped. This fixes TestExitDuringStep on Android arm and can also potentially help in other
situations, as previously the breakpoint would not get removed if the thread stopped for another
reason.

Test Plan: TestExitDuringStep passes, other tests remain unchanged.

Reviewers: tberghammer

Subscribers: tberghammer, aemerson, lldb-commits

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

llvm-svn: 237448

show more ...

[NativeProcessLinux] Fix potential race during thread exit

Summary:
This is the same issue as we had in D9145 for thread creation. Going through the full
ThreadDidStop/RequestResume cycle can cause

[NativeProcessLinux] Fix potential race during thread exit

Summary:
This is the same issue as we had in D9145 for thread creation. Going through the full
ThreadDidStop/RequestResume cycle can cause a deferred notification to fire, which is not correct
when we are ignoring an event and resuming the thread. In this case it doesn't matter much since
the thread will die after that anyway, but for correctness, we should do the same thing here.
Also treating the SIGTRAP case the same way.

Test Plan: Tests continue to pass.

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 237445

show more ...

LLDB build broke after applying patch http://reviews.llvm.org/D9706

This patch fixes the issue.

llvm-svn: 237421