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
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
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
Summary:
New dotest options that allow arbitrary log channels and
categories to be enabled. Also enables logging for locally run
debug servers.
Log messages are separated into separate files per test case.
(this makes it possible to log in dosep runs)
These new log files are stored side-by-side with trace files in the
session directory.
These files are deleted by default if the test run is successful.
If --log-success is specified, even successful logs are retained.
--log-success is useful for creating reference log files.
Test Plan:
add '--channel "lldb all" --channel "gdb-remote packets" --log-success'
to your dotest options
Tested on OSX and Linux
Differential Revision: http://reviews.llvm.org/D9594
llvm-svn: 236956
Converts the MAP_PRIVATE and MAP_ANON options to the target platform constants
(on which the call runs) rather than using those of the compiled host.
Test Plan:
Run test suite, the following tests requiring memory allocation / JIT support
begin passing when running mac -> linux:
Test11588.py
TestAnonymous.py
TestBreakpointConditions.py
TestCPPStaticMethods.py
TestCStrings.py
TestCallStdStringFunction.py
TestDataFormatterCpp.py
TestDataFormatterStdList.py
TestExprDoesntBlock.py
TestExprHelpExamples.py
TestFunctionTypes.py
TestPrintfAfterUp.py
TestSBValuePersist.py
TestSetValues.py
Differential Revision: http://reviews.llvm.org/D9511
llvm-svn: 236933
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
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
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
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
Summary:
This is a cleanup patch for thread state coordinator. After making processing of all events
synchronous, there is no need to have a a separate class for each event. I have moved back
processing of all events back into the TSC class. No functional change.
Test Plan: All tests continue to pass.
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9254
llvm-svn: 236576
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
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
This code is also an import from MacOSx implementation as SysV abi is
similar to what has been implemented for MacOS but may require a few tweaks.
http://reviews.llvm.org/D8538
llvm-svn: 236098
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
Summary:
Currently, launching lldb-gdbserver from platform on Android requires root for
mkfifo() and an explicit TMPDIR variable. This should remove both requirements.
Test Plan: Successfully launched lldb-gdbserver on a non-rooted Android device.
Reviewers: tberghammer, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9307
llvm-svn: 235940
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 <tberghammer@google.com>
llvm-svn: 235852
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
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
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
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
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
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
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
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
Also add "#if defined( LIBXML2_DEFINED )" around code that already used libxml2 in SymbolVendorMacOSX.cpp.
Cleaned up some warnings in ProcessGDBRemote.cpp.
llvm-svn: 235144
Typically, LLGS only sends stdout/stderr notifications when the inferior
process is running.
Because LLGS reads stdout from the process in a separate thread, sometimes
these stdout notifications can be received after the server has sent a thread
stop message. The host isn't expecting stdout to be generated by the target
after a stop message and these messages interfere with the host's request/
response paradigm.
Differential Revision: http://reviews.llvm.org/D9024
llvm-svn: 234995
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
This patch is major step towards supporting lldb on ARM.
This adds all the required bits to support register manipulation on Linux Arm.
Also adds utility enumerations, definitions and register context classes for arm.
llvm-svn: 234870
The OperatingSystem plug-ins allow code to detect threads in memory and then say "memory thread 0x11111" is backed by the actual thread 1.
You can then single step these virtual threads. A problem arose when thread specific breakpoints were used during thread plans where we would say "set a breakpoint on thread 0x11111" and we would hit the breakpoint on the real thread 1 and the thread IDs wouldn't match and we would get rid of the "stopped at breakpoint" stop info due to this mismatch. Code was added to ensure these events get forwarded and thus allow single stepping a memory thread to work correctly.
Added a test case for this as well.
<rdar://problem/19211770>
llvm-svn: 234364
The FreeBSD debug register access is a little usual, but in any case
different from Linux. As it stands it's not possible to share an
implementation of DR_OFFSET, so revert that part of r233837 and provide
a separate FreeBSD and Linux implementation.
We'll still want a better fix, but this should restore basic
functionality (and the buildbot).
llvm-svn: 234048
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
Summary:
The implementation of GDBRemoteRegisterContext relies on byte offsets to cache
register values. GPR, FPR, etc. should start on different offsets. This is
correctly done in debugserver (in DNBArchImplX86_64.cpp), but not on Linux or
FreeBSD (in RegisterInfos_x86_64.h).
Test Plan: `register read st0` no longer overwrites `rbp` on Linux with LLGS.
Reviewers: sivachandra, jingham, emaste, ovyalov, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D8685
llvm-svn: 233837
The automatic conversion from long int to lldb::addr_t caused sign
extension but for a register read it is an unwanted behaviour. Fix with
forcing different conversion path.
llvm-svn: 233176
Previously the remote module sepcification was fetched only from the
remote platform. With this CL if we have a remote process then we ask it
if it have any information from a given module. It is required because
on android the dynamic linker only reports the name of the SO file and
the platform can't always find it without a full path (the process can
do it based on /proc/<pid>/maps).
Differential revision: http://reviews.llvm.org/D8547
llvm-svn: 233061
The latter is uint64_t beacuse lldb supports arbitrary pid/platforms
but in this case we're using it as return value for fork() which might
return -1 to the parent in case the syscall fails.
Differential Revision: http://reviews.llvm.org/D8491
llvm-svn: 232926
Test Plan: No tests, this is just a debug logging function.
Reviewers: tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8453
llvm-svn: 232815
Some application on Linux an all application on android close stdout and
stderr during the libc exit stage. Previously the master file descriptor
of the pseudo terminal used to communicate with the inferior was closed
on an EOF causing a race condition and a possible SIGHUP on process
exit. After this change the master file descriptor will be closed by the
destructor of the GDBRemoteCommunicationServerLLGS class.
Differential revision: http://reviews.llvm.org/D8436
llvm-svn: 232724
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
This moves the conversion of the open options to the target platform. On mac fcntl.h has different values for O_CREAT and O_TRUNC than on linux so by transmitting the standardized lldb open options we can correctly convert them on the target platform.
Test Plan:
On linux:
lldb-server p --listen *:1234
On mac:
lldb
platform select remote-linux
platform connect connect://ip-of-linux-box:1234
target create ~/path/to/linux/binary
b main
process launch
Binary is successfully pushed to linux remote, process successfully launches and break in the main method.
Differential Revision: http://reviews.llvm.org/D8395
llvm-svn: 232634
This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
Some linux kernel reports a watchpoint hit after single stepping even
when no watchpoint was hit. This CL looks for a watchpoint which was hit
and reports a stop by trace if it haven't found any.
Differential revision: http://reviews.llvm.org/D8081
llvm-svn: 232482
The file path is currently required on android because the executables
only contain the name of the system libraries without their path. This
CL add an extra field to the qModuleInfo packet to return the full path
of a modul and add logic to locate a shared module on android.
Differential revision: http://reviews.llvm.org/D8221
llvm-svn: 232156
This CL change the logic used to terminate the monitor thread of
NativeProcessLinux to use a signal instead of pthread_cancel as
pthread_cancel is not supported on android.
Differential revision: http://reviews.llvm.org/D8205
llvm-svn: 232155
Previously it was fetched only if the architecture isn't valid, but the
architecture can be valid without containing all information about the
current target (e.g. missing os).
Differential revision: http://reviews.llvm.org/D8057
llvm-svn: 232153
This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly.
Differential Revision: http://reviews.llvm.org/D8186
llvm-svn: 231966
Summary:
ProcessGDBRemote::AsyncThread nuked its own thread handle upon exiting. This prevented the main
thread from joining it correctly in StopAsyncThread. I address this by moving the Reset() call to
StopAsyncThread, after the join.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8218
llvm-svn: 231915
Thic change have effect wehn the AVX registers aren't available with
reporting the count of user registers without them.
Differential revision: http://reviews.llvm.org/D8111
llvm-svn: 231638
Previously it was initialized by ProcessLinux but lldb-server don't
contain ProcessLinux anymore so it have to be initialized by
NativeProcessLinux also.
Differential revision: http://reviews.llvm.org/D8080
llvm-svn: 231482
Setting it from the Target architecture cause problems when the target
archiutecture is filled just by examining the executable because in that
case the OS isn't set.
Differential revision: http://reviews.llvm.org/D8035
llvm-svn: 231234
The deadlock occurred when the Attach or the Launch operation failed for
any reason.
Differential revision: http://reviews.llvm.org/D8030
llvm-svn: 231231
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
Previously the operation thread is stopped with a cancel event but
pthread_cancel is not supported on android. This CL creates a custom
operation which asks the operation thread to exit without any pthread
call.
Differential revision: http://reviews.llvm.org/D7937
llvm-svn: 230945
Summary:
syscalls involving pid/tid on 32 bit binaries are failing with
"Invalid argument" because the uint64_t arguments are too wide.
Reviewers: clayborg, ovyalov, sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7963
llvm-svn: 230817
Summary:
Before this fix the FileSpec::GetPath() returned string which might be without '\0' at the end.
It could have happened if the size of buffer for path was less than actual path.
Test case:
```
FileSpec test("/path/to/file", false);
char buf[]="!!!!!!";
test.GetPath(buf, 3);
```
Before fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/pa!!!"
```
After fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/p"
```
Reviewers: zturner, abidh, clayborg
Reviewed By: abidh, clayborg
Subscribers: tberghammer, vharron, lldb-commits, clayborg, zturner, abidh
Differential Revision: http://reviews.llvm.org/D7553
llvm-svn: 230787
Summary:
They'll be set anyway when the thread starts running, so the launching threads
should just ignore the set request.
Reviewers: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7914
llvm-svn: 230671
The DebuggerThread was detecting the launch error, but it was
ignored by ProcessWindows::DoLaunch, causing LLDB to wait forever
in the debugger loop.
This fixes the test case that explicitly attempts to launch a
process from a non-existant path.
Patch by Adrian McCarthy
Differential Revision: http://reviews.llvm.org/D7874
llvm-svn: 230523
Earlier this week I was able to get clang-cl on Windows to be
able to self host. This opened the door to being able to
get a whole new slew of warnings for the Windows build.
This patch fixes all of the warnings, many of which were real
bugs.
llvm-svn: 230522
Add O_TRUNC when opening file for redirecting stdout and stderr of the
process. It is neccessary because if the file exists then on some
platform the original content is kept while it isn't overwritten by the
new data causing pollution of the saved stdout and stderr.
llvm-svn: 230492
This new class makes it easier to change the timeout of a
GDBRemoteCommunication instance for a short time and then restore it to
its original value.
Differential revision: http://reviews.llvm.org/D7826
llvm-svn: 230319
With the previous implementation the protocol used by the client and the
server for the response was different and worked only by an accident.
With this change the communication is fixed and the return code from
mkdir and chmod correctly captured by lldb. The change also add
documentation for the qPlatform__[mkdir,chmod] packages.
Differential revision: http://reviews.llvm.org/D7786
llvm-svn: 230213
Summary:
This patch enables evaluation of DWARF expressions setting the CFA during stack unwinding.
This makes TestSigtrampUnwind "almost" pass on linux. I am not enabling the test yet since the
symbol name for the signal trampoline does not get resolved properly due to a different bug, but
apart from that, the backtrace is sane.
I am unsure how this change affects Mac. I think it makes the unwinder prefer the DWARF unwind
plan instead of some custom platform-dependant plan. However, it does not affect the end result
- the stack unwinding works as expected.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7792
llvm-svn: 230211
Summary:
This change refactors UnwindPlan::Row to be able to store the fact that the CFA is value is set
by evaluating a dwarf expression (DW_CFA_def_cfa_expression). This is achieved by creating a new
class CFAValue and moving all CFA setting/getting code there. Note that code using the new
CFAValue::isDWARFExpression is not yet present and will be added in a follow-up patch. Therefore,
this patch should not change the functionality in any way.
Test Plan: Ran tests on Mac and Linux. No regressions detected.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7755
llvm-svn: 230210
CopyContext is necessary to safely get the XState, but LLDB doesn't currently
use the XState. CopyContext is available as of Windows 7 SP1, so it can't be
used on Vista. Furthermore, it requires the Windows 8 SDK it compile,
making the baseline for compiling and running LLDB higher than necessary.
Patch by: Adrian McCarthy
Reviewed by: Zachary Turner
Differential Revision: http://reviews.llvm.org/D7572
llvm-svn: 229710
This commit merges lldb-platform and lldb-gdbserver into a single binary
of the same size as each of the previous individual binaries. Execution
mode is controlled by the first argument being either platform or
gdbserver.
Patch from: flackr <flackr@google.com>
Differential revision: http://reviews.llvm.org/D7545
llvm-svn: 229683
Currently it is uses the same code used on linux. Will be replaced with
android specific code if needed.
Differential Revision: http://reviews.llvm.org/D7613
llvm-svn: 229371
Fixed test case to copy redirected stdout/stderr files from remote
target to host
llgs wasn't bothering to put the pty master file handle in the right
place if stdout/stderr were redirected to a file. It is still needed
for stdin.
Corrected some log message text
llvm-svn: 229141
'-Winconsistent-missing-override' warning. I suggest folks use this to
ensure that override is consistently used to mark virtual function
overrides.
llvm-svn: 229084
both a user process dyld and for a kernel binary -- we
will decide which to prefer after one or both have been
located.
It would be faster to stop the search thorugh the core
segments one we've found a dyld/kernel binary - but that
may trick us into missing the one we would prefer.
<rdar://problem/19806413>
llvm-svn: 228910
Summary: Coverity warns that unsigned >= 0 is always true, and k_first_gpr_powerpc happens to be 0. Quiet Coverity by changing that comparison instead to a static_assert(), in case things change in the future.
Reviewers: emaste
Reviewed By: emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7576
llvm-svn: 228908
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.
This allows processes using the API to pump stdin into a remote
inferior process.
It fixes a hang in TestProcessIO.py when running against a remote
target.
llvm-svn: 228419
Summary:
After closing all the leaked file descriptors to the inferior tty, the following problem occured:
- when stdin, stdout and stderr are redirected, there are no slave descriptors open (which is good)
- lldb has a reader thread, which attempts to read from the master end of the tty
- this thread receives an EOF
- in response, it closes it's master end
- as this is the last open file descriptor for the master end, this deletes the tty and sends
SIGHUP to the inferior (this is bad)
I fix this problem by making sure the master end remains open for the duration of the inferior
process by storing a copy of the file descriptor in ProcessMonitor. I create a copy to avoid
ownership issues with the reading thread.
Reviewers: ovyalov, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7440
llvm-svn: 228391
* Fix cmake script for android x86
* Reorder includes to avoid collision between system macros and local
variables in clang framework
Differential Revision: http://reviews.llvm.org/D7435
llvm-svn: 228388
* Set the state of the process into running/stepping on continue/step operations
* Add mutex to use transactions in Thread State Coordinator
** It is required because the events from two Signal Handler or form a Signal handler and a Resume request shouldn't overlap
* Send Stop Replay Packet only when the state of the process changed
Differential Revision: http://reviews.llvm.org/D7374
llvm-svn: 228387
Summary:
This adds the register plumbing, as well as register reading in FreeBSD core
dumps. Further work on the POSIX/FreeBSD ProcessMonitor is required in order to
support ptrace access to these registers.
Reviewers: tfiala, emaste
Reviewed By: emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D7039
llvm-svn: 228278
Summary:
Both LLDB and LLGS are leaking file descriptors into the debugged process. This plugs the leak by
closing the unneeded descriptors. In one case I use O_CLOEXEC, which I hope is supported on
relevant platforms. I also added a regression test and plugged a fd leak in dosep.py.
Reviewers: vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7372
llvm-svn: 228130
Remove implicit stop action on $vCont package for threads where no
explicit action or default action specified based on the specification
(they have to stay in there original state).
llvm-svn: 227933
NativeProcessLinux::MonitorSignal was automatically resuming threads
that stopped due to a signal. This is inconsistent with the
behavior of lldb and gdb. This change removes the automatic resume.
Fixes
TestSendSignal.py
TestSignalsAPI.py
if PLATFORM_LINUX_FORCE_LLGS_LOCAL is in the environment vars.
llvm-svn: 227918
Note this code path should not happen - it implies a bug in another part of
the code. For the thread to receive the stop signal as it is handled, the
and for it to already have a stop reason, it implies the kernel was able to
tell the thread that it stopped while it was stopped. More likely this
seems to indicate a bug where an actual thread start was not getting correctly
logged. If it does get hit, we'll want to understand the sequence to figure
out if it is truly legitimate or if it implies another bug.
llvm-svn: 227916
It looks like Shawn's fix addresses what the initial hijacking was trying
to accomplish per conversations with Greg and Jim. The hijacking was
causing several tests to hang (#61, #62, #63, #64, #67, possibly more).
These tests now just fail rather than hang with this modification.
llvm-svn: 227914
* When the thread state coordinator is told to skip sending a stop request
for a running thread that is ignored (e.g. the thread that steps in a
step operation is technically running and should not have a stop sent
to it, since it will stop of its own accord per the kernel step operation),
ensure the deferred signal notification logic still waits for the
skipped thread. (i.e. we want to defer the notification until the
stepping thread is indeed stopped, we just don't want to send it a tgkill).
* Add ThreadStateCoordinator::RequestResumeAsNeeded(). This variant of the
RequestResume() method does not call the error function when the thread
is already running. Instead, it just logs that the thread is already
running and skips the resume operation. This is useful for the case of
vCont;c handling, where we tell all threads that they should be running.
At the place we're calling, all we know is "we want this thread running if
it isn't already," and that's exactly what this command does.
* Formatting change (minor) in NativeThreadLinux logging.
llvm-svn: 227913
See https://github.com/tfiala/lldb/issues/75. Not fixed yet but
continuing to push this further.
Fixes:
* Resume() now skips doing deferred notifications if we're doing a
vCont;{c,C}. In this case, we're trying to start something up,
not defer a stop notification. The default thread action stop
mode pickup was triggering a stop because it had at least one
stop, which was wrong in the case of a continue. (Bug introduced
by previous change.)
* Added a variant to ThreadStateCoordinator to specify a set of
thread ids to be skipped when triggering stop notifications to
non-stopped threads on a deferred signal call. For the case of
a stepping thread, it is actually told to step (and is running)
for a brief moment, but the thread state coordinator would think
it needed to send the stepping thread a stop, which id doesn't
need to do. This facility allows me to get around that cleanly.
With this change, behavior is now reduced to something I think is
essentially a different bug:
* Doing a step into libc code from my code crashes llgs.
* Doing a next out of a function in my own code crashes llgs.
llvm-svn: 227912
Tracked down while working on https://github.com/tfiala/lldb/issues/75.
This is not a complete fix for that issue, but moves us farther along.
Fixes:
* When a thread step is requested via vCont:{s,S}, Resume() now marks
the stepping thread as (1) currently stepping and (2) does trigger
the deferred signal for the stepped thread. This fixes a bug where
we were actually triggering a deferred stop cycle here for the non-stepping
thread since the single step thread was not part of the Resume()
deferred signal mechanism. The stepping thread is also marked in
the thread state coordinator as running (via a resume callback).
* When we get the SIGTRAP signal for the step completion, we don't
do a deferred signal call - that happened during the vCont:{s,S}
processing in Resume() already. Now we just need to mark that
the stepping thread is now stopped. If this is the last thread
in the set that needs to stop, it will trigger the process/delegate
stop call that will notify lldb. Otherwise, that'll happen when
the final thead we're waiting for stops.
Misc:
* Fixed up thread stop logging to use a leading 0 (0x%PRIx32) so
we don't get log lines like 0x5 for 0x05 SIGTRAP.
llvm-svn: 227911
* Fixed bug in run loop where run loop return enum was being treated
erroneously like an int, causing the TSC event loop to terminate
prematurely.
* Added an explicit scope in NativeProcessLinux::Resume() for the
threads lock lifetime. (This was likely unnecessary but is
more explicit.)
* Fixed a bug in ThreadStateCoordinator where resume execution was
not updating the internal state about the thread assumed to be
running now. I'll add a test and upstream this in a moment.
* Added a verbose logging mechanism to event processing within
ThreadStateCoordinator. It is currently enabled when the
'log enable lldb thread' is true upon inferior launch/attach.
llvm-svn: 227909
This patch fixes TestRegisters on Linux with LLGS
Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish
lldb internal registers (e.g.: DR0-DR7) during register counting.
Update GDBRemoteCommunicationServer to skip lldb internal registers on
read/write register and on discover register.
Submitted for Tamas Berghammer
llvm-svn: 226959
Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
introduced subtle bugs in two places in
RegisterContextLLDB::GetFullUnwindPlanForFrame where
it specifically wanted to get an eh_frame unwind plan
and was using "Get CallSite UnwindPlan" as synonymous
with that. But now we have two different types of
unwind plan that can be returned in that case, and
compact unwind won't behaves as needed.
<rdar://problem/19528559>
llvm-svn: 226631
This hooks up the changes necessary to set the trap flag on the
CPU and properly manage the process and thread's resume state
and private state so that the ThreadPlan does its thing.
Stepping still doesn't work as of this change, because there are
some issues with stack frames where it doesn't update the thread's
frame list correctly when it breaks inside of a function, but
I will try to fix that separately.
llvm-svn: 226221
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
These fix various issues with path handling and disable a few tests
which use features of LLVM which are not yet supported on Windows.
llvm-svn: 226042
This is currently controlled by a setting:
(lldb) settings set target.process.python-os-plugin-path <path>
Or clearing it with:
(lldb) settings clear target.process.python-os-plugin-path
The process will now reload the OperatingSystem plug-in.
This was implemented by:
- adding the ability to set a notify callback for when an option value is changed
- added the ability for the process plug-in to load the operating system plug-in on the fly
- fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits
- adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user
- fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded
llvm-svn: 225831
it more generally available.
Add checks to UnwindAssembly_x86::AugmentUnwindPlanFromCallSite() so
that it won't try to augment an UnwindPlan that already describes
the function epilogue.
Add a test case for backtracing out of _sigtramp on Darwin systems.
This could probably be adapted to test the same thing on linux/bsd but
the function names of sigtramp and kill are probably platform
specific and I'm not sure what they should be.
llvm-svn: 225578
so that we will use the UnwindPlan's rule for providing the stack
pointer BEFORE we use the trick of using the callee's CFA address
as the stack pointer. When we're in a _sigtramp frame, the CFA of
the _sigtramp stack frame is not the same as the stack pointer value
when the async interrupt occurred -- we need to use the eh_frame
rules for retrieving the correct value.
<rdar://problem/18913548>
llvm-svn: 225427
This was causing a race condition where DoDestroy() would acquire
the lock and then initiate a shutdown and then wait for it to
complete. But part of the shutdown involved acquiring the same
lock from a different thread. So the main thread would timeout
waiting for the shutdown to complete and return too soon.
The end result of this is that SBProcess::Kill() was broken on
Windows.
llvm-svn: 225297
This fixes compilation failures in the 64-bit build of LLDB on Windows.
Patch by Aidan Dodds
Differential Revision: http://reviews.llvm.org/D6704
llvm-svn: 224528
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
a register value that is live in the stack frame 0 register context.
Fixes a problem where retrieving a register value on stack frame #n
would involved O(n!) stack frame checks. This could be very slow on
a deep stack when retrieving register values that had not been
modified/saved by any of the stack frames. Not common, but annoying
when it was hit.
<rdar://problem/19010211>
llvm-svn: 223843
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
This reverts commit 4a5ad2c077166cc3d6e7ab4cc6e3dcbbe922af86.
Windows doesn't support select() for pipe objects, and this also fails
to compile on Windows. Reverting this until we can get it sorted out
to keep the windows build working.
llvm-svn: 223392
This is a temporary workaround to get deferred breakpoint
resolution working until Bug 21720 is addressed. Even with this
workaround, it will only resolve deferred breakpoints in the
executable module, and not in a shared library.
llvm-svn: 223273
Previously if we got a DoDestroy while stopped at a breakpoint, we
would detach and then say the process had exited. This is completely
wrong, as it resulted in the python script incorrectly assuming that
the process had actually exited and trying to delete the image, when
in fact it had done no such thing.
The fix employed here is that when we get a DoDestroy, we do 3 steps:
1) initiate a termination sequence on the process
2) If we were stopped handling an exception of any kind, mask it and
let the program resume, causing the program to see the termination
request and exit on its own.
3) Let the program exit normally, and close all of our handles before
returning control back to DoDestroy.
This fixes Bug 21722 and Bug 21723.
llvm-svn: 223272
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on
that same stack frame before it tries the fallback unwind plan
on the "next" or callee frame.
In RegisterContextLLDB::TryFallbackUnwindPlan, when we're
trying the fallback unwind plan to see if it is valid, make
sure we change all of the object ivars that might be used in
the process of fetching the CFA & caller's saved pc value
and restore those if we decide not to use the fallback
unwindplan.
<rdar://problem/19035079>
llvm-svn: 222601
LLDB supports many different register numbering schemes, and these
are typically prefixed with an indicator that lets the user know
what numbering scheme is used. The gcc numbering scheme is
prefixed with gcc, and there are similar ones for dwarf, gdb,
and gcc_dwarf.
LLDB also contains its own internal numbering scheme, but the enum
for LLDB's numbering scheme was prefixed differently. This patch
changes the names of these enums to use the same naming scheme for
the enum values as the rest of the register kinds by removing gpr_
and fpu_ prefixes, and instead using lldb_ prefixes for all enum
values.
Differential Revision: http://reviews.llvm.org/D6351
Reviewed by: Greg Clayton
llvm-svn: 222495
Running a diff against lldb-x86-register-enums.h and the file
modified in this patch, the two enums were completely identical.
Deleting one of them to reduce code noise.
llvm-svn: 222478
This implements the skeleton of a RegisterContext for Windows.
In particular, this implements support only for x86 general purpose
registers.
After this patch, LLDB on Windows can perform basic debugging
operations in a single-threaded inferior process (breakpoint,
register inspection, frame select, unwinding, etc).
Differential Revision: http://reviews.llvm.org/D6322
Reviewed by: Greg Clayton
llvm-svn: 222474
where it is retrieving the Return Address register contents
on a target where that's a thing. If we fail to get a valid
RA, we force a switch to the fallback unwind plan. This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211>
llvm-svn: 222301
Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type. This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185
Previously we were directly updating the thread list and stopping
and restarting the process every time threads were created. With
this patch, we queue up thread launches and thread exits, resolve
these all internally, and only update the threads when we get an
UpdateThreadList call. We now only update the private state on
an actual stop (i.e. breakpoint).
llvm-svn: 222178
This creates a TargetThreadWindows class and updates the thread
list of the Process with the main thread. Additionally, we
fill out a few more overrides of Process base class methods. We
do not yet update the thread list as threads are created and/or
destroyed, and we do not yet propagate stop reasons to threads as
their states change.
llvm-svn: 222148
RegisterContextLLDB. I have core files of half a dozen tricky
unwind situations on x86/arm and they're all working pretty much
correctly at this point, but we'll need to keep an eye out for
unwinder regressions for a little while; it's tricky to get these
heuristics completely correct in all unwind situations.
<rdar://problem/18937193>
llvm-svn: 221866
This sends notifications for module load / unload to the process
plugin, and also manages the state more accurately during the
loading sequence.
Similar work by Virgile Bello was referenced during the
implementation of this patch.
Differential Revision: http://reviews.llvm.org/D6224
llvm-svn: 221807
Due to a previous multi-threaded design involving message
passing, we used message classes to pass event information
to the delegate. Since the multi-threaded design has gone
away, we simplify this by passing event arguments as direct
function parameters, which is more clear and easier to
understand.
llvm-svn: 221806
After r221575 TestCallStopAndContinue and TestCallThatRestarts started
crashing on FreeBSD with a null temporary_module_sp in
RegisterContextLLDB::InitializeNonZerothFrame().
llvm-svn: 221805
The addition of RegisterNumber introduced a bug where if the PC is stored in a
return address register, such as on ARM and PowerPC, this register number is
retrieved and used, but never checked in the row if it's saved. Correct this by
setting the variable that's used to the new register number.
Patch by Jason Molenda.
llvm-svn: 221790
Summary:
Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add
full stack unwind support to the PowerPC/PowerPC64 ABI. Also, add a new
register set for powerpc32-on-64, so the register sizes are correct. This also
requires modifying the ProcessMonitor to add support for non-uintptr_t-sized
register values.
Reviewers: jasonmolenda, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6183
llvm-svn: 221789
Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788
This patch implements basic support for stopping at breakpoints
and resuming later. While a breakpoint is stopped at, LLDB will
cease to process events in the debug loop, effectively suspending
the process, and then resume later when ProcessWindows::DoResume
is called.
As a side effect, this also correctly handles the loader breakpoint
(i.e. the initial stop) so that LLDB goes through the correct state
sequence during the initial process launch.
llvm-svn: 221642
it in RegisterContext.cpp.
There's a lot of bookkeeping code in RegisterContextLLDB where it has
to convert between different register numbering schemes and it makes
some methods like SavedLocationForRegister very hard to read or
maintain. Abstract all of the details about different register numbering
systems for a given register into this new class to make it easier
to understand what the method is doing.
Also add register name printing to all of the logging -- that's easy to
get now that I've got an object to represent the register numbers.
There were some gnarly corner cases of this method that I believe
I've translated correctly - initial testing looks good but it's
possible I missed a corner case, especially with architectures which
uses a link-register aka return address register like arm32/arm64.
Basic behavior is correct but there are a lot of corner casese that are
handled in this method ...
llvm-svn: 221577
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.
Also add a backtrace test with an attempt to elicit this
particular layout. It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting. We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.
<rdar://problem/16051613>
llvm-svn: 221575
Originally the idea was that we would queue requests to a master
thread that would dispatch them to other slave threads each
responsible for debugging an individual process. This might make
some scenarios more scalable and responsive, but for now it seems
to be unwarranted complexity for no observable benefit.
llvm-svn: 221561
In the llgs world, ProcessWindows will eventually go away and
we'll implement a different protocol. This patch decouples
ProcessWindows from the core debug loop so that this transition
will not be more difficult than it needs to be.
llvm-svn: 221405
Renamed monitor -> driver, to make clear that the implementation here
is in no way related to that of other process plugins which have also
implemented classes with similar names such as DebugMonitor.
Also created a DebugEventHandler interface, which will be used by
implementors to get notified when debugging events happen in the
inferiors.
llvm-svn: 221322
let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.
This fix is for <rdar://problem/18683658>.
I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719>
that I've fixed over the last 6-9 months.
llvm-svn: 221238
is "invalid" -- it is past the end of the stack trace. Add a new
method IsCompletedStackWalk() so we can tell if an invalid stack
frame is from a complete backtrace or if it might be worth re-trying
the last unwind with a different method.
This fixes the unwinder problems Ryan Brown was having with go
programs. The unwinder can (under the right circumstances) still
destructively replace unwind plans permanently - I'll work on
that in a different patch.
<rdar://problem/18683658>
llvm-svn: 221229
When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.
These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process. This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6037
llvm-svn: 221207
The details are: large packets (like large memory reads (m packets) or large binary memory reads (x packet)) can get responses that come in across multiple read() calls. The while loop that was added meant that if only a partial packet came in (like only "$abc" coming for a response) GDBRemoteCommunication::CheckForPacket() was called, it would deadlock in the while loop because no more data is going to come in as this function needs to be called again with more data from another read. So the original fix will need to be corrected and resubmitted.
<rdar://problem/18853744>
llvm-svn: 221181
Summary:
SIGPROF is used for profiling processes (with google-perftools for
instance), which results in the inferior receiving a SIGPROF from the
kernel every few milliseconds. Instead of stopping the debugging session
and notifying the user of this, we should just pass the signal and keep
running.
This follows the behavior we have in UnixSignals.cpp.
Test Plan: Run LLDB on linux with a binary using google-perftools, see that execution gets interrupted all the time because we receive SIGPROF. Apply the patch, everything works fine.
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D5953
llvm-svn: 221011
Summary:
This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are
some issues still:
* Breakpoints don't work well on powerpc64.
* Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host.
* Backtraces don't work. This is due to PowerPC ABI using a backchain pointer
in memory, instead of a dedicated frame pointer register for the backchain.
* Breakpoints on functions without debug info may not work correctly for 32-bit
powerpc.
Reviewers: emaste, tfiala, jingham, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D5988
llvm-svn: 220944
function because of a '1u' making it a 32-bit value
when it really needed to be a 64-bit value. Trivial to fix
once I figured out what was going on.
clang static analzyer fixit.
llvm-svn: 220022
in GetFullUnwindPlanForFrame() - the code was mostly checking
that we had an active Process and ABI but not always.
clang static analyzer fixit.
llvm-svn: 219772
This implements Host::LaunchProcess for windows, and in doing so
does some minor refactor to move towards a more modular process
launching design.
The original motivation for this is that launching processes on
windows needs some very windows specific code, which would live
most appropriately in source/Host/windows somewhere. However,
there is already some common code that all platforms use when
launching a process before delegating to the platform specific
stuff, which lives in source/Host/common/Host.cpp which would
be nice to reuse without duplicating.
This commonality has been abstracted into MonitoringProcessLauncher,
a class which abstracts out the notion of launching a process using
an arbitrary algorithm, and then monitoring it for state changes.
The windows specific launching code lives in ProcessLauncherWindows,
and the posix specific launching code lives in ProcessLauncherPosix.
When launching a process MonitoringProcessLauncher is created, and
then an appropriate delegate launcher is created and given to the
MonitoringProcessLauncher.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5781
llvm-svn: 219731
With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.
Several log lines have been added around PTY and stdout/stderr redirection
logic on the lldb client side.
Regarding remote llgs execution, see the following:
With these changes, remote llgs with $O now works properly:
$ lldb
(lldb) platform select remote-linux
(lldb) target create ~/some/inferior/exe
(lldb) gdb-remote {some-target}:{port}
(lldb) run
The sequence above will correctly redirect stdout/stderr over gdb-remote $O,
as is needed for remote debugging. That sequence assumes there is a lldb-gdbserver
exe running on the target with {some-host}:{port}.
You can replace the gdb-remote command with a '(lldb) platform connect
connect://{target-ip}:{target-port}'. If you do this and have a
lldb-platform running on the remote end, it will go ahead and launch
llgs for lldb for each target instance that is run/attached.
For local debugging with llgs, the following sequence also works, and
uses local PTYs instead to avoid $O and extra gdb-remote messages:
$ lldb
(lldb) settings set platform.plugin.linux.use-llgs true
(lldb) target create ~/some/inferior/exe
(lldb) run
The above will run the inferior using llgs on the local host, and
will use PTYs rather than $O redirection.
This change also removes the logging that happened after the fork but
before the exec when llgs is launching a new inferior process. Some
aspect of the file handling during that portion of code would not do
the right thing with log handling. We might want to go back later
and have that communicate over a pipe from the child to parent to pass
along any messages that previously were logged in that section of code.
llvm-svn: 219578
See http://reviews.llvm.org/D5695 for details.
This change does the following:
Enable lldb-gdbserver (llgs) usage for local-process Linux debugging.
To turn on local llgs debugging support, which is disabled by default, enable this setting:
(lldb) settings set platform.plugin.linux.use-llgs-for-local true
Adds a stream-based Dump() function to FileAction.
Pushes some platform methods that Linux (and FreeBSD) will want to share with MacOSX from PlatformDarwin into PlatformPOSIX.
Reviewed by Greg Clayton.
llvm-svn: 219457
Adds a test to verify that a thread resume request marks the thread as running
after doing the resume callback. This test fails without the corresponding
ThreadStateCoordinator.cpp change.
Fixes the code where that state was not maintained.
llvm-svn: 219412
the backtrace, try falling back to the architecture default
unwind plan and see if we can backtrace a little further.
<rdar://problem/18556719>
llvm-svn: 219247
As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548
llvm-svn: 219143
Added tests and impl to make sure the following errors are reported:
* Notifying a created thread that we are already tracking.
* Notifying a thread death for a thread we don't know about.
llvm-svn: 218900
Now that ThreadStateCoordinator errors out on threads in unexpected states,
it has enough information to know which threads need stop requests fired
when we want to do a deferred callback on a thread's behalf. This change
adds a new method, CallAfterRunningThreadsStop(...), which no longer
takes a set of thread ids that require stop requests. It's much harder
to misuse this method and (with newer error logic) it's harder to
correctly use the original method. Expect the original method that takes
the set of thread ids to stop to disappear in the near future.
Adds several tests for CallAfterRunningThreadsStop().
llvm-svn: 218897
Added tests to verify that the coordinator signals an error if
the given thread to resume is unknown, and if the thread is through to
be running already.
Modified resume handling code to match tests.
llvm-svn: 218872
ThreadStateCoordinator changes:
* Most commands that run in the queue now take an error handler that
will be called with an error string if an error occurs during processing.
Errors generally stop the operation in progress. The errors are checked
at time of execution. This is intended to help flush out ptrace/waitpid/state management
issues as quickly as possible.
* Threads now must be known to the coordinator before stops can be reported,
resumes can be requested, thread deaths can be reported, or deferred stop
notifications can be made. Failure to know the thread will cause the coordinator
to call the error callback for the event being processed. Threads are introduced
to the system by the NotifyThreadCreate method.
* The NotifyThreadCreate method now takes the initial state of the thread being
introduces to the system. We no longer just assume the thread is running.
The test cases were cleaned up, too:
* A gtest test fixture is now used, which allows creating less verbose helper
methods that setup common pieces of callback code for some method invocations.
Net result: the tests are simpler to read and shorter to write.
llvm-svn: 218833
ThreadIDFunc => ThreadIDFunction
LogFunc => LogIDFunction
We try to avoid abbreviations/shortened names. Adjusted function parameter names
as well to replace _func with _function.
llvm-svn: 218773
r218568 added an explicit #include of the Linux ProcessMonitor.h to
POSIXThread.cpp, rather than including just "ProcessMonitor.h" and
relying on the build infrastructure for the appropriate paths.
For now add #ifdefs in the source to use the FreeBSD or Linux header
as appropriate; a cleaner fix (and perhaps some refactoring of the
POSIX classes) should still be done later.
llvm-svn: 218762
There is a state transition that seems potentially buggy that I am capturing and
logging here, and including an explicit test to demonstrate expected behavior. See new test
for detailed description. Added logging around this area since, if we hit it, we
may have a usage bug, or a new state transition we really need to investigate.
This is around this scenario:
Thread C deferred stop notification awaiting thread A and thread B to stop.
Thread A stops.
Thread A requests resume.
Thread B stops.
Here we will explicitly signal the deferred stop notification after thread B
stops even though thread A is now resumed. Copious logging happens here.
llvm-svn: 218683
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
The thread resume block is executed in the normal flow of thread
state queued event processing. The tests verify that it is executed
when we track the thread to be stopped and skipped when we track
it to already be running.
llvm-svn: 218638
Also added a test for the reset handling. The reset/state clearing happens
as a processed queue event. The only diff vs. standard processing is that
the exec clears the queue before queueing the activity to clear internal state.
i.e. once we get an exec, we really stop doing any other queue-based activity.
llvm-svn: 218629
A new thread arriving while a pending signal notification
is outstanding will (1) add the new thread to the list of
stops expected before the deferred signal notification is
fired, (2) send a stop request for the new thread, and
(3) track the new thread as currently running.
llvm-svn: 218578
See http://reviews.llvm.org/D5495 for more details.
These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk
build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in
github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}.
llvm-svn: 218568
Tested two pending stops before notification, where one of the pending stop
requirements was already known to be stopped.
Tested pending thread stop before notification, then reporting thread with
pending stop died and verifies pending notification is made.
llvm-svn: 218559
Glad I did - caught a bug where the auto variable was not a reference
to a set and instead was a copy. I need to review rules on that!
llvm-svn: 218558
This change does the following:
* Remove test/c++/...
* Add gtest.
* Add gtest/unittest directory for unittesting individual classes.
* Add an initial Plugins/Process?linux/ThreadStateCoordinatorTest.cpp.
- currently failing a test (intentional).
- added a bare-bones ThreadStateCoordinator.cpp to Plugins/Process/Linux,
more soon. Just enough to prove out running gtest on Ubuntu and MacOSX.
* Added recursive make machinery so that doing a 'make' in gtest/ is
sufficient to kick off the existing test several directories down.
- Caveat - I currently short circuit from gtest/unittest/Makefile directly to
the one and only gtest/unittest/Plugins/Process/Linux directory. We'll need
to add the intervening layers. I haven't done this yet since to fix the
Xcode test failure correspondence, I may need to add a python layer which
might just handle the directory crawling.
* Added an Xcode project to the lldb workspace for gtest.
- Runs the recursive make system in gtest/Makefile.
- Default target is 'test'. test and clean are supported.
- Currently does not support test failure file/line correspondence.
Requires a bit of text transformation to hook that up.
llvm-svn: 218460
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
The $A handler was unnecessarily waiting for the launched app to hit a stop
before returning. Removed this code.
Renamed the llgs inferior launching code to LaunchProcessForDebugging ()
to prevent it from possibly being mistaken as code that lldb-platform uses
to launch a debugserver process. We probably want to look at breaking out
llgs-specific and lldb-platform-specific code into separate derived classes,
with common code in a shared base class.
llvm-svn: 218075
There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool.
See http://reviews.llvm.org/D5302 for more details.
Change by Shawn Best.
llvm-svn: 217818
Instead of forcing the remote arch type to MachO all the time, we
inspect the OS/vendor that the remote debug server reports and use it to
set the arch type to MachO, ELF or COFF accordingly.
See thread here for more context:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140915/012968.html
Change by Stephane Sezer.
Tested:
MacOSX 10.9.4 x86_64
Ubuntu 14.04 x86_64
llvm-svn: 217779
This is useful for checking inconsistencies between what the remote debug server thinks we are debugging and we think we are debugging. This follows the check for pointer byte size done just above.
Change by Stephane Sezer.
Tested:
Ubuntu 14.04 x86_64, llvm-3.5-built lldb
MacOSX 10.9.4, Xcode-Beta(2014-09-09)-built lldb.
llvm-svn: 217773
* Fixes the local stack variable return pointer usage in NativeThreadLinux::GetName().
* Changes NativeThreadProtocol::GetName() to return a std::string.
* Adds a unit test to verify thread names don't regress in the future. Currently only run on Linux since I know default thread names there.
llvm-svn: 217717
Apparently, PEEKUSER/POKEUSER is something x86 specific, so I had to rework it for AArch64. This fixes assertion that occurs whenever lldb started on AArch64 device tried to read PC register (or any other register)
See http://reviews.llvm.org/D5232 for more details.
Change by Paul Osmialowski.
llvm-svn: 217691
* Sends a SIGSTOP to the process.
* Fixes busted SIGSTOP handling. Now builds a list of non-stopped
that we wait for the PTRACE group-stop for. When the final must-stop
tid gets its group stop, we propagate the process state change.
Only the signal receiving the notification of the pending SIGSTOP
is marked with the SIGSTOP signal. All the rest, if they weren't
already stopped, are marked as stopped with signal 0.
* Fixes a few broken tests.
* Marks the Linux test I added earlier as expect-pass (no longer XFAIL).
Implements fix for http://llvm.org/bugs/show_bug.cgi?id=20908.
llvm-svn: 217647
This change implements this ticket:
http://llvm.org/bugs/show_bug.cgi?id=20899
Adds the qThreadStopInfo RSP command for llgs and includes a test that
verifies both debugserver and llgs respond with something reasonable
on a multithreaded app.
llvm-svn: 217549
More work on the GetName/SetName arguments (thread_t vs tid_t) is needed
but this change should restore the build and basic operation.
llvm-svn: 217502
This patch moves creates a thread abstraction that represents a
thread running inside the LLDB process. This is a replacement for
otherwise using lldb::thread_t, and provides a platform agnostic
interface to managing these threads.
Differential Revision: http://reviews.llvm.org/D5198
Reviewed by: Jim Ingham
llvm-svn: 217460
This makes sure that nothing that requires Python is being built
when the LLDB_DISABLE_PYTHON flag is being passed in.
It also changes a use of CPPFLAGS to CPP.Flags since the former is overridden
when external flags are passed in while the later is not. I'm not sure exactly
why LLDB_DISABLE_PYTHON is in CXXFLAGS rather than CPPFLAGS,
but cleaning that up is for another commit.
Differential Revision: http://reviews.llvm.org/D4918
llvm-svn: 217414
This cleans up a couple of warnings [-Wcovered-switch-default] from the build by
removing the default case from a couple of switches which are fully covered.
This is generally better as it will help identify when a new item is added to
the enumeration but the use sites are not updated.
llvm-svn: 217376
detct unwind loops but there was a code path through there (using
architecture default unwind plans) that didn't do the check, and
could end up with an infinite loop unwind. Move that code into a
separate method and call it from both places where it is needed.
Also remove the use of ABI::FunctionCallsChangeCFA in that check.
I thought about it a lot and none of the architecutres that we're
supporting today can have a looping CFA.
Since the unwinder isn't using ABI::FunctionCallsChangeCFA() and
ABI::StackUsesFrames(), and the unwinder was the only reason
those methods exists, I removed them from the ABI and all its
plugins.
<rdar://problem/17364005>
llvm-svn: 216992
See http://reviews.llvm.org/D5108 for details.
This change does the following:
* eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter.
* replaces the Process UnixSignals storage with a shared pointer.
* adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used.
* adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant.
* replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process.
This change also enables some future patches that will enable llgs to be used for local Linux debugging.
llvm-svn: 216748
This patch accepts environment variables of the form:
LLDB_DEBUGSERVER_EXTRA_ARG_n
where n starts with 1, and may continue nearly indefinitely (up through std::numeric_limits<uint32_t>::max()).
The code loops around, starting with 1, until it doesn't find one of the environment variables. For each one it does find defined, it appends the environment variable's contents to the end of the debugserver/llgs startup command line issued when the stub is started for local debugging.
I am using this to add arbitrary startup commands to the llgs command line for turning on additional logging. For example:
export LLDB_DEBUGSERVER_EXTRA_ARG_1="-c"
export LLDB_DEBUGSERVER_EXTRA_ARG_2="log enable -f /tmp/llgs_packets.log gdb-remote packets"
export LLDB_DEBUGSERVER_EXTRA_ARG_3="-c"
export LLDB_DEBUGSERVER_EXTRA_ARG_4="log enable -f /tmp/llgs_process.log lldb process"
llvm-svn: 216745
Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented.
Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too.
See the following for more details:
http://reviews.llvm.org/D4580http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html
Change by Paul Osmialowski.
llvm-svn: 216737
This change:
* properly captures execs in NativeProcessLinux.
* clears out all non-main-thread thread metadata in NativeProcessLinux on exec.
* adds a DidExec() method to the NativeProcessProtocol delegate.
* clears out the auxv data cache when we exec (on Linux).
This is a small part of the llgs for local Linux debugging work going on here:
https://github.com/tfiala/lldb/tree/dev-llgs-local
I'm breaking it into small patches.
llvm-svn: 216670
I copied this originally based on what debugserver was doing. This appears to
be incorrect and unncessary for Linux. The LinuxSignals on the lldb side
don't look for these and therefore they get handled incorrectly.
Leaving the hook in place since I think darwin will continue to need to
translate those signal numbers.
llvm-svn: 216564
creating the ModuleSpec to load the core file - we won't have a fat
core file and we can end up with cpu subtype mismatches if the core
file header isn't written out completely accurately. We need to
be a little loose in this particular case.
<rdar://problem/17843388>
llvm-svn: 216498
This change addresses this bug:
http://llvm.org/bugs/show_bug.cgi?id=20755
This change:
* Modifies llgs to send triple instead of cputype and cpusubtype when not on Apple platforms in qProcessInfo.
* Modifies lldb's GDBRemoteCommunicationClient to handle the triple returned from qProcessInfo if given.
When given, it will prefer to use triple over cputype and cpusubtype.
* Adds gdb-remote protocol tests to verify that cputype and cpusubtype are specified on darwin, and that triple is specified on Linux.
llvm-svn: 216470
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
This continues the effort to get Host code moved over to HostInfo,
and removes many more instances of preprocessor defines along the
way.
llvm-svn: 216195
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
Fixes include:
1 - added new FileSpec method: bool FileSpec::Readable()
2 - detect when an executable is not readable and give an appropriate error for:
(lldb) file /tmp/unreadablefile
3 - detect when a core file is not readable and give an appropriate error
4 - detect when a specified core file doesn't exist and give an appropriate error
<rdar://problem/17727734>
llvm-svn: 215741
FileAction was previously a nested class in ProcessLaunchInfo.
This led to some unfortunate style consequences, such as requiring
the AddPosixSpawnFileAction() funciton to be defined in the Target
layer, instead of the more appropriate Host layer. This patch
makes FileAction its own independent class in the Target layer,
and then moves AddPosixSpawnFileAction() into Host as a result.
Differential Revision: http://reviews.llvm.org/D4877
llvm-svn: 215649
i386 eh_frame register numbering, encoding a darwin-specific
bug in the register numbering. Update the definitions to be
the correct values, Darwin can use the register numbers from
debugserver. Patch from Tong Shen.
llvm-svn: 215488
Added llgs/debugserver gdb-remote tests around SIGABRT and SIGSEGV signal reception
notification. Found a few bugs in exception signal handling in Linux llgs. Fixed those.
llvm-svn: 215458
This patch moves the logic of many common socket operations into
its own class lldb_private::Socket. It then modifies the
ConnectionFileDescriptor class, and a few users of that class,
to use this new Socket class instead of hardcoding socket logic
directly.
Finally, this patch creates a common interface called IOObject for
any objects that support reading and writing, so that endpoints
such as sockets and files can be treated the same.
Differential Revision: http://reviews.llvm.org/D4641
Reviewed by: Todd Fiala, Greg Clayton
llvm-svn: 214984
call Target::SetArchitecture instead of modifying a
reference to the target's architecture so that the
target logging can show that the arch has been changed.
llvm-svn: 214667
This patch creates a simple ProcessWindows process plugin.
The only thing it knows how to do currently is create processes.
Differential Revision: http://reviews.llvm.org/D4681
llvm-svn: 214094
GDBRemoteRegisterContext::ReadRegisterBytes and
GDBRemoteRegisterContext::WriteRegisterBytes to ensure we don't try
to read/write off the end of the register buffer. This should never
happen but we've had some target confusion in the past where it
did; adding the checks is prudent to avoid crashing here if it happens
again.
<rdar://problem/16450971>
<rdar://problem/16458182>
llvm-svn: 213829
to the remote side (QStartNoAckMode) - it may take a little longer
than normal to get a reply.
In debugserver, hardcode the priority for several threads so they
aren't de-prioritized when a user app is using system resources.
Also, set the names of the threads.
<rdar://problem/17509866>
llvm-svn: 213828
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
This change enables lldb-platform for Linux. In addition, it does the following:
* fixes Host::GetLLDBPath() to work on Linux/*BSD for ePathTypeSupportExecutableDir-relative paths.
* adds more logging and comments around lldb-platform startup and remote lldb-platform usage.
* refactors lldb-platform remote-* support for Darwin and Linux into PlatformPOSIX. This, in theory, is the bulk of what is needed for *BSD to make remote connections to lldb-platform as well (although I haven't tested that yet). FreeBSD can make similar changes to their Platform* as was made here for PlatformLinux to pick up the rest of the bits.
* teaches GDBRemoteCommunication to use lldb-gdbserver for non-Apple hosts.
llvm-svn: 213707
Also track down the required binary by trying to locate the main executable module through LLDB's symbol and executable file locating code.
<rdar://problem/16570258>
llvm-svn: 213199
Now that llgs supports communicating the 0-port choose-a-port
mechanism and can communicate that back to a caller via the
--named-pipe option (at parity with debugserver), we use this
mechanism to always start llgs and debugserver gdb-remote
protocol tests without needing to use some port arbitration
mechanism. This eliminates some potential intermittent failures vs. the
previous random port and collision-avoidance strategy used.
llvm-svn: 212923
These fix the broken debian lldb build, which is using g++ 4.7.2.
TypeFormat changes:
1. stopped using the C++11 "dtor = default;" construct.
The generated default destructor in the two derived classes wanted
them to have a different throws() semantic that was causing 4.7 to
fail to generate it. I switched these to empty destructors defined
in the .cpp file.
2. Switched the m_types map from an ordered map to an unordered_map.
g++ 4.7's c++ library supports the C++11 emplace() used by TypeFormat
but the same c++ library's map impl does not. Since TypeFormat didn't
look like it depended on ordering in the map, I just switched it to
a std::unordered_map.
NativeProcessLinux - g++ 4.7 chokes on lexing the "<::" in
static_cast<::pid_t>(wpid). g++ 4.8+ and clang are fine with it.
I just put a space in between the "<" and the "::" and that cleared
it up.
llvm-svn: 212681
See http://reviews.llvm.org/D4366 for details.
Change by Paul Paul Osmialowski
Today this is the only problem that I'm facing trying to cross-compile lldb for AArch64 using Linaro's toolchain.
PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS are not defined for AArch64
These things can be defined different ways for other architectures, e.g. for x86_64 Linux, asm/ptrace-abi.h defines them as preprocessor constants while sys/ptrace.h defines them in enum along with corresponding PT_* preprocessor constants
NativeProcessLinux.cpp includes sys/ptrace.h
To avoid accidental redefinition of enums with preprocessor constants, I'm proposing this patch which first checks for PT_* preprocessor constants then checks for PTRACE_* constants then when it still can not find them, it defines preprocessor constants.
Similar approach was already used for PTRACE_GETREGSET and PTRACE_SETREGSET constants; in this case however it was easier, since enum values in sys/ptrace.h and preprocessor constants shared all exactly the same names (e.g. there's no additional PT_GETREGSET name defined).
llvm-svn: 212225
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
- Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms
- Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll
- More build fixes for Windows
The pending issues are that two Python modules, termios and pexpect are not available on Windows.
These are currently required for the Python command interpreter to be used from within LLDB.
llvm-svn: 212111
There were a few places where we were not catching the possibility of negative
error codes in waitpid() calls. This change fixes those remaining after
the llgs branch fixes to ProcessMonitor.
Change by Shawn Best.
llvm-svn: 212107
With _HAS_EXCEPTIONS=0, Windows' version of <thread> will fail to
compile because it calls __uncaught_exception(), which is compiled
out due to _HAS_EXCEPTIONS=0. This just creates a stub version
of __uncaught_exception() which always fails.
llvm-svn: 212076
Also moves NativeRegisterContextLinux* files into the Linux directory.
These, like NativeProcessLinux, should only be built on Linux or a cross
compiler with proper headers.
llvm-svn: 212074
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
Both NativeProcessLinux (in llgs branch) and Linux Host.cpp had similar code to handle /proc
file reading. I factored that out into a new Linux-specific ProcFileReader class and added a method
that the llgs branch will use for line-by-line parsing.
This change also adds numerous Linux-specific files to Xcode that were missing from the Xcode
project files.
Related to https://github.com/tfiala/lldb/issues/27
llvm-svn: 212015
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
mistake in the lock acquistion in HistoryUnwind and HistoryThread.
We've got a deadlock with one use case of HistoryUnwind; I
need to figure out what lock ordering is causing this and fix
it for real.
<rdar://problem/17411904>
llvm-svn: 211541
When a stub reported $#00 (unsupported) for _M and _m
packets, the unsupported response was not handled and
the client then marked the _M/_m commands as definitely
supported. However, they would always fail, preventing
lldb's fallback InferiorCallMmap-based allocation strategy
from being used to attempt to allocate memory in the inferior
process space.
llvm-svn: 211425
to modify the same UnwindTable object simultaneously. Fix
HistoryThread and HistoryUnwind's mutex lock acqusition to
retain the lock for the duration of the operation instead of
releasing the temporary immediately.
<rdar://problem/17055023>
llvm-svn: 211241
Issue discovered during the GSoC 2014 project implementing FreeBSD
kernel support. The existing elf-core Process plugin crashed trying
to read from /dev/mem (the kernel memory device).
Patch by Mike Ma.
llvm-svn: 211102
RegisterSets are assumed to be terminated by this value. Loops over
register set values would fail without LLDB_INVALID_REGNUM terminating
the list. This change adjusts the static check to account for the
size of the register set regnum list being one larger than the expected
valid register set count.
llvm-svn: 210964
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
Changes include:
- ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands
- ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK).
- Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo
- PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using:
(lldb) platform select ios-simulator
(lldb) platform process list
- debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables
- GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly
<rdar://problem/17060217>
llvm-svn: 209852
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
read requests into smaller chunks; some remote kdp stubs
cannot handle memory reads larger than a KB or two & will
error out.
<rdar://problem/16983125>
llvm-svn: 209341
debugserver now returns $X09 as the immediate response to
a $k kill process request rather than $W09.
ProcessGDBRemote now properly handles X as indication of
a process exit state.
The @debugserver_test and @lldb_test for $k now properly expects
an X notification (signal-caused exit) after killing a just-attached
inferior that was still in the stopped state.
llvm-svn: 209108
Also moved it into the lldb_private namespace.
The llgs branch is making use of this interface and its use is not
strictly limited to POSIX.
llvm-svn: 209016
See thread here:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-May/003992.html
This is meant to address case 3 that I recently broke with an earlier
change to rectify usage of the $qC message for thread ids, specifically:
3. TOT lldb <=> gdbserver (without $qProcessInfo support and not Apple/iOS).
llvm-svn: 208741
$qC from debugserver now returns the current thread's thread-id (and, like $?, will set a current thread if one is not already selected). Previously it was returning the current process id.
lldb will now query $qProcessInfo to retrieve the process id. The process id is now cached lazily and reset like other cached values. Retrieval of the process id will fall back to the old $qC method for vendor==Apple and os==iOS if the qProcessInfo retrieval fails.
Added a gdb remote protocol-level test to verify that $qProcessInfo reports a valid process id after launching a process, while the process is in the initial stopped state. Verifies the given process id is a currently valid process on host OSes for which we know how to check (MacOSX, Linux, {Free/Net}BSD). Ignores the live process check for OSes where we don't know how to do this. (I saw no portable way to do this in stock Python without pulling in other libs).
llvm-svn: 208241
data if it is available.
Change ProcessGDBRemote's maximum read/write packet size from a
fixed 512 byte value to asking the remote gdb stub what its maximum
is, using up to 128kbyte sizes if that's allowed, and falling back
to 512 if the remote gdb stub doesn't advertise a max packet size.
Add a new "process plugin packet xfer-size" command that can be used
to override the maximum packet size (although not exceeding any packet
size maximum published by the remote gdb stub).
<rdar://problem/16032150>
llvm-svn: 208058
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
- CTRL+C wasn't clearing the command in lldb
- CTRL+C doesn't work in python macros in lldb
- Ctrl+C no longer interrupts the running process that you attach to
<rdar://problem/15949205>
<rdar://problem/16778652>
<rdar://problem/16774411>
llvm-svn: 207816
currently associated with a given thread, on relevant targets.
Change the queue detection code to verify that the queues
associated with all live threads are included in the list.
<rdar://problem/16411314>
llvm-svn: 207160
When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro. This is a standard macro, defined in stddef.h. Include
this header to ensure that offsetof is declared.
llvm-svn: 206702
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
As the Linux PTRACE_KILL behaviour is not used by LLDB, rename
BringProcessIntoLimbo to Kill, and change the implementation to simply
call kill() instead of using ptrace.
Thanks to Todd F for testing (Ubuntu 12.04, gcc 4.8.2).
Sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3159
llvm-svn: 205337
Store the gpr data in a DataBufferHeap and use a DataExtractor to
extract register values with appropriate endianness. This avoids hard-
coding the register count, and with some further work would allow this
class to provide generic register context storage for any CPU.
llvm-svn: 205329
On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
For now I'm committing only the FreeBSD change, until the Linux change
(review D3159) is successfully tested.
http://llvm.org/pr18894
llvm-svn: 205315
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
condition where we could end up killing debugserver (and thus the target) before it had a chance
to detach.
Also fix debugserver to send the OK AFTER it detaches to avoid the same race condition.
<rdar://problem/16202713>
llvm-svn: 205043
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
Fix Windows build by adding JITLoaderGDB and ProcessElfCore.
RegisterContext: fixes for Windows build: sizeof(GPR::register) didn't work, switched to sizeof(((GPR*)NULL)->register).
llvm-svn: 203667
memcpy cannot be passed NULL. Ensuring that the destination pointer is non-NULL
requires checking success. Rather than performing the success check at that
point, increasing indentation an additional level, fold it into the previous
statement.
llvm-svn: 203359
not going to key off of the ELF object file like I'd intended.
Revert my change in r203205; also revert Greg's change in
r203107 which builds ProcessElfCore on non-Linux/FreeBSD systems
for the moment until we can straighten this out.
llvm-svn: 203207
ProcessMachCore because it doesn't check the format of the file up front. (this is only now
happening because of Greg's change in r203178 to build ProcessElfCore for non-Linux/FreeBSD
hosts).
<rdar://problem/16257533>
llvm-svn: 203205
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
ProcessGDBRemote::GetAuxvData obtains the auxv from a remote gdbserver (via a binary-data packet), and returns the data as a DataBufferSP.
The patch includes a small fix to GDBRemoteCommunicationClient::SendPacketsAndConcatenateResponses() to support binary file format packet returns (by not assuming each binary packet is a null-terminated string when concatenating them).
llvm-svn: 202907
This change uses a fixed known offset for the Linux i386 DR0 register.
This change also undoes the 32-bit wordsize change from r169645 that
revolved around being 32-bit/64-bit friendly in
WriteRegOperation::Execute within the Linux ProcessMonitor.cpp. I ran
all the tests on x86_64 Linux with no failures. I also ran some simple
tests with 32-bit Linux exe on x86_64 host and 32-bit linux exe on
i686 32-bit host and these worked fine.
Note (from Todd): the UserData struct in the Linux i386 register
context (only used by Linux i386 host running Linux 32-bit inferior)
is out of sync with what shows up in the sys/user.h for an 32-bit
Linux build (per an earlier change of mine to make it look more like
x86_64 host running x86 exe). I think we should (1) make i386 Linux
targets run using the same register context (and correct ones) on i386
and x86_64 linux hosts if that is possible, and (2) we could use some
tests around the register handling, particularly to verify things like
DR0 registers are in the right spots on host/target combos that we can
verify vs. known correct values.
Change by Matthew Gardiner.
llvm-svn: 202887
This seems a little more straightforward and is equivalent to r201457
for ELF core files. A case for FreeBSD i386 is also added (it was
incorrectly using the 64-bit register context and corrupting mememory).
Better (user-facing) error handling is still needed.
Review: http://llvm-reviews.chandlerc.com/D2765
llvm-svn: 202549
This change fixes up issues with specifying the size of the i386
register infos for FPU registers. The bug was that for the i386
register context, the size of the FPU registers were still being
computed based on the x86_64 FXSAVE structure.
This change permits the FPR_SIZE macro to optionally be defined
outside of RegisterInfos_i386.h, which RegisterContextLinux_i386.cpp
does properly. It redefines the FPR_i386 structure with all the
accessible parts that RegisterInfos_i386.h wants to see, which we had
not done before when we made the overall size of the structure
properly sized a recently.
This change also modifies POSIXThread to create a
RegisterContextLinux_i386 only when the host is 32-bit; otherwise, it
uses the RegisterContextLinux_x86_64, which works properly for 32-bit
and 64-bit inferiors on a 64-bit host.
I tested this debugging a Linux x86 exe on an x86 host (Ubuntu 13.10
x86), and debugging a Linux x86 exe and a Linux x86-64 exe on an
x86-64 host (Ubuntu 12.04 LTS). Those cases all worked.
Thanks to Matthew Gardiner who discoverd may key insights into
tracking down the issue. The motivation for this change and some of
the code originates from him via this thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140224/010554.html
llvm-svn: 202428
This fix changes thee x86 32-bit floating point register area to be
the proper size independent of the host platform.
Note as of this change list, this register context is not yet used
since selecting it exposes issues with watchpoint assertions.
Change by Matthew Gardiner.
llvm-svn: 202285
class. If we try to unwind a stack frame to find a caller stack
frame, and we fail to get a valid-looking frame, AND if the UnwindPlan
we used is an assembly-inspection based UnwindPlan, then we should
throw away the assembly-inspection UnwindPlan and try unwinding with
the architectural default UnwindPlan.
This code path won't be taken if eh_frame unwind instructions are available -
lldb will always prefer those once it's off the zeroth frame.
The problem I'm trying to fix here is the class of unwind failures that
happen when we have hand-written assembly on the stack, with no eh_frame,
and lldb's assembly parser fails to understand the assembly. People usually
write their hand-written assembly to follow the frame-pointer-preserving
conventions of the platform so the architectural default UnwindPlan will
often work. We won't have the spill location for most of the non-volatile
registers if we fall back to this, but it's better than stopping the unwind
prematurely.
This is a bit of a tricky change that I believe is correct, but if we get
unwinds that go of into the weeds / unwind bogus frames at the end of the
stack, I'll need to revisit it.
<rdar://problem/16099440>
llvm-svn: 201839
Implement x86_64 debug register read/write in support of hardware
watchpoints. Hoist LinuxThread::TraceNotify code back into
POSIXThread::TraceNotify()
Patch by John Wolfe.
We still need to rework this later to avoid the #ifdef FreeBSD.
llvm-reviews.chandlerc.com/D2572
llvm.org/pr16706
llvm-svn: 201706
This way the same RegisterContext class can support i386 and
amd64/x86_64 core files.
With some further refinement we should be able to merge all of the
processor-specific RegisterContextPOSIX_* classes into a single shared
one.
llvm-svn: 201577
ProcessElfCore::ParseThreadContextsFromNoteSegment was leaking
ThreadData for each ELF note found in core file. We now allocate it
only once and use std::unique_ptr to ensure it is always being freed.
While at it make ParseFreeBSDThrMisc and ParseFreeBSDPrStatus take
ThreadData by reference, rather than pointer, since those arguments are
not optional.
Patch by Piotr Rak.
http://llvm-reviews.chandlerc.com/D2813
llvm-svn: 201473
This seems like a more straightforward approach for instantiating the
appropriate RegisterContext* class, made possible by Michael Sartain's
cleanup of the POSIX RegisterContext class hierarchy in r190647.
Better (user-facing) error handling is still needed.
llvm-svn: 201457
specify a list of functions which should be treated as trap handlers.
This will be primarily useful to people working in non-user-level
process debugging - kernels and other standalone environments.
For most people, the trap handler functions provided by the Platform
plugin will be sufficient.
<rdar://problem/15835846>, <rdar://problem/15982682>
llvm-svn: 201386
Michael Sartain refactored RegisterContextPOSIX_* in r192332, and I must
have missed the now-shadowed variable when I rebased the FreeBSD MIPS64
register context after that.
llvm-svn: 201334
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
Elf core files were collapsing core segments when the virtual memory
addresses were contiguous without checking if the core-file-backed
memory region was the same size as the segment's VMA region. Without
this extra check, any time regions were collapsed but the core-backed
region was smaller (and thus had a zero-filled hole at the end), the
collapse operation would break VMA to core file lookups for subsequent
collapsed regions.
This change fixes the following bug:
http://llvm.org/bugs/show_bug.cgi?id=18769
llvm-svn: 201214
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
GDBProcessCommunicationServer now optionally takes a PlatformSP that
defaults to the default platform for the host.
GDBProcessCommunicationServer::LaunchProcess () now uses the platform
to launch the process.
lldb-gdbserver now takes an optional --platform={platform_plugin_name}
or -p {platform_plugin_name} command line option. If no platform is
specified, the default platform for the host is used; otherwise, if
the platform_plugin_name matches a registered platform plugin or
matches the default platform's name (which is not necessarily
registered by name in the case of 'host'), that platform is used. If
the platform name cannot be resolved, lldb-gdbserver exits after
printing all the available platform plugin names and the default
platform plugin name.
llvm-svn: 200266
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
if the remote stub provided enough information to identify it in the
qProcessInfo packet response. (e.g. for an Apple device where we know
it is Mach-O, the cpu type & cpu sub type).
<rdar://problem/15847901>
llvm-svn: 200253
This change modifies the 'A' command handler's launch code to launch
with LaunchProcess (). The net effect is that the default process
monitoring that LaunchProcess () adds will kick in, allowing the
GDBRemoteCommunicationServer to be able to reap processes started with
this facility correctly. Later, in the case of lldb-gdbserver, we'll
also have the proper process monitoring going on to really debug the
inferior process.
llvm-svn: 200246
This patch addresses a bug where in a multi-threaded program a new
signal from the inferior may be received before all group-stop
messages from an earlier signal have been handled.
Patch by Andrew MacPherson
llvm-svn: 200226
There are a couple of pieces:
* some lazy-evaluation members that store info listed in a qSupported response
* new method SendPacketsAndConcatenateResponses which is used for
fetching fixed-size objects from the remote gdbserver by using multiple
packets if necessary (first use will be to fetch shared-library XML files).
llvm-svn: 200072
right after the space for it is allocated on the stack, instead of trying
to initialize it in all the different places in this method. It's too easy
for another uninitialized code path to sneak in as it is written right now.
llvm-svn: 200066
GDBRemoteCommunicationServer::LaunchProcess () now uses the built-up
ProcessLaunchArgs rather than clearing and setting items from the
function arguments. I added setters for the arguments and launch
flags, which lldb-gdbserver uses for its specification of the
commandline-specified startup app (if one is specified).
LaunchProcess () also adds a new reaper monitor that it applies to
the launched process if no process monitor has already been applied.
This addresses an issue where the 'k' command would generate (possibly
false) warnings about not being able to positively state whether a
killed process actually terminated. GDBRemoteCommunicationServer now
definitely knows the disposition of its children.
llvm-svn: 199959
Pavel Labath