Added helper methods:
prep_debug_monitor_and_inferior(): properly handles
the two cases of running the stub against an inferior process
launched by the stub, and one attached to by the stub. See
docs for function: simplifies test creation for tests that want
to test the same operations against a launched and attached inferior.
Added the q{f,s}ThreadInfo and $qC response comparison test (verifies
they both return the same thing) when the process is attached rather
than launched by the stub.
Modified the previous two tests added to make use of the new
prep_debug_monitor_and_inferior() facility.
llvm-svn: 209318
The First test verifies that qThreadInfo queries work for stub-launched processes.
The second test verifies that $qC after stub-launched inferior returns the same
thread as the qThreadInfo queries.
llvm-svn: 209314
The multi request-response test infrastructure support was adding
the optional request suffix iteration index as decimal but it needed
to be hex per spec. This change fixes that.
llvm-svn: 209234
Added support for gdb remote protocol capture/playback where there is a query/multiple-response
pattern. The new playback entry supports:
- a general query command (key: next_query or query)
- an optional first-query command if that differs from the subsequent queries (key: first_query)
- an end regex for matching anything that would signify that the query/multi-response
iteration has come to an end. An assumption is that the end regex is not a content
package we care about aside from ending the iteration. (key: end_regex)
- an optional 0-based index appended to the end of the query command
(key: append_iteration_suffix), default: False.
- a key used to collect responses from the query. Any response from the gdb remote
that doesn't match the end-of-iteration regex is captured in the playback context
dictionary using the key specified. That key will be an array, where each array
entry is one of the responses from the query/multi-response iteration. (key: save_key).
- a runaway response value, defaulting to 10k, where if this many responses is captured,
assume the ending condition regex is invalid, or the debug monitor is doing something
goofy that is going to blow out memory or time. (key: runaway_response_count, default: 10000)
See the lldbgdbserverutils.MultiResponseGdbRemoteEntry class for details.
A MultiResponseGdbRemoteEntry is added by adding an element to the GdbRemoteTestSequence
(via GdbRemoteTestSequence.add_log_lines), using a dictionary, where the "type" key
is set to "multi_response", and the rest of the keys in the dictionary entry are
set to the keys documented for MultiResponseGdbRemoteEntry.
Added helper functions to add the required entry to grab all qRegisterInfo responses.
Added another helper to parse the qRegisterInfo response packets into an array of
dictionaries, where each key:value in the dictionary comes from the register info
response packet.
Added a test to verify that a generic register exists for the program counter,
frame pointer, stack pointer and cpu flags across all register info responses.
Added a test to verify that at least one register set exists across all register
info responses.
llvm-svn: 209170
Need to spend a little more time with suppressing the debugserver 64-to-32 bit warnings.
Will re-submit after I get the warnings properly suppressed.
llvm-svn: 209151
Checks that at at least qRegisterInfo0 responds with a valid
register info reply packet. The packet is parsed and validates
that all keys come from the documented set of valid keys. It
then validates that a minimum set of expected keys
are present in the returned packet.
This test is set to pass on debugserver and fail on llgs TOT.
llvm-svn: 209109
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
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
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
Use a map rather than a vector to store the objects managed by the shared
cluster since mostly want this for random lookup, so the map is much faster.
llvm-svn: 209010
- Tested with Eclipse, likely to work with other GDB/MI compatible GUIs.
- Some but not all MI commands have been implemented. See MIReadme.txt for more info.
- Written from scratch, no GPL code, based on LLDB Public API.
- Built for Linux, Windows and OSX. Tested on Linux and Windows.
- GDB/MI Command Reference, https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html
llvm-svn: 208972
Checks that the pid reported by $qProcessInfo matches the pid that was
launched as the attach test subject.
test exe now supports "sleep:{sleep_seconds}" command line argument.
llvm-svn: 208782
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
the SystemRuntime to check if a thread will have any problems
performing an inferior function call so the driver can skip
making that function call on that thread. Often the function
call can be executed on another thread instead.
<rdar://problem/16777874>
llvm-svn: 208732
The clean line is failing under Ubuntu 12.04/gcc. It cleans fine
without it on MacOSX. It doesn't clean right on Linux but at least
now it doesn't fail the test.
llvm-svn: 208713
Python defines _XOPEN_SOURCE and _POSIX_C_SOURCE unconditionally. On Linux,
this is problematic as glibc's features.h defines these values if _GNU_SOURCE is
defined to the value that is currently implemented. Python defines it to the
versions that it requires, which may be different. Undefine the macros on Linux
(technically, this should be safe to do globally) before including the python
headers.
llvm-svn: 208520
another way to indicate that this register is a generic
Return Address register (in addition to "ra") - this is
used primarily by OperatingSystem plugins.
Correctly annotate the UnwindPlan created by EmulateInstructionARM64
to indicate that it was not sourced from a compiler and it
is valid at every instruction.
<rdar://problem/16639754>
llvm-svn: 208390
$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
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
This is a missing part of LLDB commit r207122.
Patch by Brooks Davis in FreeBSD ports commit r353052
llvm-svn: 208204
Added a test validating that $qC after an inferior launch via $A
returns a thread id that an immediately followig $? reports for the
active thread. This is currently skipped on debugserver (the thread
ids don't match) and isn't yet implemented in TOT for llgs.
llvm-svn: 208061
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
Pushed gdbremote protocol sequence expectations into a separate
class and defer matching of llgs/debugserver output to the
sequence entry. Pre-step to adding regex matching and
grouped content collecting.
No longer require anything before the read/send packet
portion of slurped-up log lines used for setting up
gdb remote test sequences. Several packet logging options
produce a wide range of content before the read/send packet.
Added helpers to TestLldbGdbServer to clean up test setup
and test expectations matching.
llvm-svn: 207998
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
Tests added for debugserver and lldb-gdbserver. lldb-gdbserver marked as
XFAIL on top of tree.
Added build_gdbremote_A_packet test helper to construct a gdbremote A
launch packet from a list of args.
llvm-svn: 207568
This now builds lldb-gdbserver on all Linux and FreeBSD architectures
rather than being locked to x86_64 architectures only.
Please note lldb-gdbserver is not yet functional, this just enables
the non-x86_64 Linux/FreeBSD build using the configure/make build
system.
--This line, and
those below, will be ignored--
M tools/Makefile
llvm-svn: 207556
- Remove default for switch which covers all enumeration values
- Remove unused functions
LSL_C is left in the source under #if 0, as it may be needed in the
future for emulating other instructions.
Differential Revision: http://reviews.llvm.org/D3528
llvm-svn: 207449
TestLldbGdbServer now supports both lldb-gdbserver (llgs) and
debugserver tests. Similar to the dsym/dwarf tests, they allow
running the same underlying gdb remote protocol tests against
lldb-gdbserver and debugserver. This will help make sure the
protocol-level tests for lldb-gdbserver faithfully represent
what debugserver does on OS X.
Switched back gdb remote protocol test logging to warning
and above (accidentally submitted it at debug level in a
recent commit).
llvm-svn: 207395
Adds try/except blocks around clean-up code. Prevents a race between gdb
remote kill command reception by llgs (which leads llgs to shut down)
and the pexpect server kill (which can fail if the kill command handling
completes first). Warnings are emitted on the logger for any clean-up
code that fails.
llvm-svn: 207273
optional path prior to the file base name.
On Linux x86_64 (Ubuntu 12.04) I am sometimes getting a full path
on the stderr.txt. This changes the test for target.error-path and
target.output-path settings to ignore any optional directory before
the expected file base name.
llvm-svn: 207272
It looks like on 18th April clang added dependency from clangCodeGen.a to
LLVMProfileData.a and since then lldb have problem with linking to
clangCodeGen.a due to missing symbols.
This adds LLVMProfileData.a to USEDLIBS to fix that problem.
Patch by Robert Matusewicz.
llvm-svn: 207216
Currently if you run _any_ python, python has the "lldb.debugger" global variable and it has a strong reference to a lldb_private::Debugger since it is a lldb::SBDebugger object with a shared pointer.
This makes sure that your LLDB command interpreter history is saved each time you quit command line LLDB.
llvm-svn: 207164
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
values of variables in the Materializer.
The Materializer should not write the variable
back if its new value is the *same* as the old
value, not if the new value is *different*.
<rdar://problem/16712205>
llvm-svn: 207148
The FreeBSD package building cluster installs e.g. 'python2.7', but no
plain 'python' to avoid version-related issues.
CMake's FindPythonInterp locates an interpreter with such a name and
provides it in the PYTHON_EXECUTABLE variable. Use that if it's set,
falling back to the original '/usr/bin/env python' otherwise.
Patch by Brooks Davis in FreeBSD ports commit r352012
llvm-svn: 207122
This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself
llvm-svn: 207046
Todd Fiala