History log of /llvm-project/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp (Results 251 – 275 of 290)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2fe1d0ab 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Moving header files from source/Host/common to proper location.

llvm-svn: 227929


# 37c768ca 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Make ThreadStateCoordinator to handle properly failed stop/resume operations.

llvm-svn: 227928


# 28e57429 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Share crash information between LLGS and local POSIX debugging with
CrashReason class. Deliver crash information from LLGS to lldb via
description field of thread stop packet.

llvm-svn: 227926


# 86fd8e45 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Modify ThreadStateCoodrinator in order to resume threads if stop wasn't requested.

llvm-svn: 227924


# 97ccc294 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Refactor ptrace commands in NativeProcessLinux to use Error as result return type.

llvm-svn: 227923


# 911a6dca 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

LLGS local - signal stops inferior in debugger

NativeProcessLinux::MonitorSignal was automatically resuming threads
that stopped due to a signal.  This is inconsistent with the
behavior of lldb and

LLGS local - signal stops inferior in debugger

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

show more ...


# e9547b80 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Fix up NativeProcessLinux::Interrupt() to use thread state coordinator mechanism.

llvm-svn: 227917


# aab58633 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Added code to prevent "administrative stop" from overwriting a real stop reason.

Note this code path should not happen - it implies a bug in another part of
the code. For the thread to receive the

Added code to prevent "administrative stop" from overwriting a real stop reason.

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

show more ...


# c0e5ac84 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Fix step commands that mix running threads and stepping threads.

This fixes https://github.com/tfiala/lldb/issues/62.

llvm-svn: 227915


# 9d617ba6 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Disabled local-llgs hijacking of state on startup; passed along signo to killed process.

It looks like Shawn's fix addresses what the initial hijacking was trying
to accomplish per conversations wit

Disabled local-llgs hijacking of state on startup; passed along signo to killed process.

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

show more ...


# b8af31d4 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Fix some bugs in llgs thread state handling.

* 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

Fix some bugs in llgs thread state handling.

* 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

show more ...


# 03f12d6b 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

llgs: more work on thread stepping.

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'

llgs: more work on thread stepping.

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

show more ...


# ae29d395 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

llgs: fix up some handling of stepping.

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

llgs: fix up some handling of stepping.

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

show more ...


# 938fcf63 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

llgs: fixed a bug in deferred signal thread id; added coordinator enqueue logging.

The deferred signal thread id was being set with the process id
unintentionally in NativeProcessLinux::CallAfterRun

llgs: fixed a bug in deferred signal thread id; added coordinator enqueue logging.

The deferred signal thread id was being set with the process id
unintentionally in NativeProcessLinux::CallAfterRunningThreadsStop().

llvm-svn: 227910

show more ...


# fa03ad2e 03-Feb-2015 Chaoren Lin <chaorenl@google.com>

Get initial thread state coordinator integration working.

* Fixed bug in run loop where run loop return enum was being treated
erroneously like an int, causing the TSC event loop to terminate
pr

Get initial thread state coordinator integration working.

* 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

show more ...


Revision tags: llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1
# 54539338 17-Nov-2014 Oleksiy Vyalov <ovyalov@google.com>

Fix broken NativeProcessLinux.cpp after signature change of ResolveExecutable.

llvm-svn: 222184


# 6edef204 17-Nov-2014 Oleksiy Vyalov <ovyalov@google.com>

Fix broken Linux build after signature change of ResolveExecutable.

llvm-svn: 222182


# 1339b5e8 13-Nov-2014 Oleksiy Vyalov <ovyalov@google.com>

Refactor NativeProcessLinux::AttachToProcess in order to avoid reinterpret_cast from NativeProcessProtocol* to NativeProcessLinux*.

llvm-svn: 221906


# 50d60be3 11-Nov-2014 Shawn Best <sbest@blueshiftinc.com>

Fix error handling in NativeProcessLinux::AttachToInferior: http://reviews.llvm.org/D6158

llvm-svn: 221647


# 8da0bf3b 08-Nov-2014 Shawn Best <sbest@blueshiftinc.com>

LLGS Android target support - for Andy Chien : http://reviews.llvm.org/D6166

llvm-svn: 221570


# 75f47c3a 11-Oct-2014 Todd Fiala <todd.fiala@gmail.com>

llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.

With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.

llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.

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

show more ...


# cacde7df 27-Sep-2014 Todd Fiala <todd.fiala@gmail.com>

Enable llgs to build against experimental Android AOSP lldb/llvm/clang/compiler-rt repos.

See http://reviews.llvm.org/D5495 for more details.

These are changes that are part of an effort to support

Enable llgs to build against experimental Android AOSP lldb/llvm/clang/compiler-rt repos.

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

show more ...


# acee96ae 23-Sep-2014 Zachary Turner <zturner@google.com>

Fix up the HostThread interface, making the interface simpler.

Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5417

llvm-svn: 218325


# 615eb7e6 19-Sep-2014 Greg Clayton <gclayton@apple.com>

Test suite runs better again after recent fixes that would select a platform if a "file a.out" auto selected a different platform than the selected one.

Changes include:
- fix it so you can select t

Test suite runs better again after recent fixes that would select a platform if a "file a.out" auto selected a different platform than the selected one.

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

show more ...


# 850f9a25 19-Sep-2014 Todd Fiala <todd.fiala@gmail.com>

Fix typo in Linux ASLR logging.

llvm-svn: 218133


1...<<1112