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
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
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
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
The deadlock occurred when the Attach or the Launch operation failed for
any reason.
Differential revision: http://reviews.llvm.org/D8030
llvm-svn: 231231
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
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
* 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:
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
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/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
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
