redirecting output to a path that will work well on host or target.
copying file from output location to location on local host that
test will read from
llvm-svn: 228217
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
The member m_nTimes is used in rest of lldb-mi to represent hit count.
In one place, it was assigned a wrong value (number of locations). This
resulted in lldb-mi showing a hit count of variable 1 when it was created.
Committed as obvious.
llvm-svn: 228150
Summary: This reduces the bloat in the source tree and makes the tests more consistent.
Reviewers: vharron, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7373
llvm-svn: 228134
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
lldb-mi has 3 threads.
1. One that waits for user intput.
2. Another waits for 1st thread to get input command.
3. Waits for events from lldb.
2 & 3 needs to be synchronized so that they don't end up
doing things at same time. For example, while "break insert" is
processing, we can get a breakpoint event. Depending on where we
are in "break-insert", it can have different behavior. In some
cases, it can cause breakpoint to be deleted too. I have added a
mutex so that command processing and event processing are done
exclusively and they are not running at the same time.
In longer term, I think thread 2 & 3 should be merged to be only
one thread which can wait on command or events.
Reviewed in http://reviews.llvm.org/D7371.
llvm-svn: 228128
number of bytes to write into the inferior process, the "default byte size" will be 1.
In that case, we want to copy the entire file into memory. The code was looking for
a default byte size of 0 to indicate that the user had not provided a specific # of
bytes to copy; adjust that to 1 to match the actual default value.
<rdar://problem/18074973>
llvm-svn: 228067
Summary:
The Android dynamic linker reports only the basename of each SO entry, so for
the above check to be successful, we need to compare it to the basename of the
main executable.
This also has a nasty side-effect when working with older version of
Android (verified on platform version 16), and debugging PIE
executables: the dynamic linker has a bug and reports the load address
of the main executable (which is a shared object, because PIE) to be 0.
We then try to update the list of loaded sections for all shared
objects, including the main executable, and set the load address to 0,
which breaks everything that relies on resolving addresses in the main
executable (breakpoints, stepping, etc). This commit also fixes that broken
behavior when debugging on older Androids. This bug doesn't happen on newer
Android versions (verified for Android L).
Test Plan: Run test suite on linux.
Reviewers: clayborg, tfiala, richard.mitton
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7188
llvm-svn: 228057
On windows, signal handler is reset to default once a signal is received.
This causes doing ctrl-c twice on console (or pressing suspend button twice
in eclipse ide which uses SIGINT to stop the debuggee) to crash lldb-mi on
windows. Although there is very tiny window (after signal handler is called
and before we restore the handler) where default handler will be in place.
But this is hardly a problem in practice as IDEs generally disable their suspend
button once it has been presses.
llvm-svn: 227964
This patch fixes execution of CLI commands in MI mode. The CLI commands are
executed using "-interpreter-exec" command. The bug was in the
CMICmnLLDBDebugSessionInfo class which contained the following members:
SBProcess, SBTarget, SBDebugger and SBListener, but CLI commands don't affect
them and they aren't updated. Therefore some members can contain incorrect
(or obsolete) reference and it can cause an error. My patch removes these
members and uses getters that provides the updated instance every time it is used.
Patch from Ilia K ki.stfu@gmail.com. Approved by Greg.
llvm-svn: 227958
This was causing code that opened multiple targets to try and get a path to debugserver from the GDB remote communication class, and it would get the LLDB path and some instances would return empty strings and it would cause debugserver to not be found.
<rdar://problem/18756927>
llvm-svn: 227935
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
LLGS debugging is outputting different thread stop reasons than
local linux debugging. The stop reasons are reasonable so I've left
left them alone. Might update them to match darwin in the future.
llvm-svn: 227920
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
Reid Kleckner