lldb-gdbserver and NativeProcessProtocol will use MemoryRegionInfo
but don't want to pull in Process.h. Pull this declaration and
definition out into its own header.
llvm-svn: 210213
Added two new tests: one to verify that a test exe heap address
returned is readable and writeable, and a similar one to verify
a test exe stack address is readable and writeable.
Ran the main.cpp test exe code through the Xcode re-indenter.
I was using TextMate to edit the test's C++ code alongside the
Python code but last check-in found that it was not handling
tabs/indentation the way I am intending it.
Modified test exe to require C++11.
Refactored gdb remote python code's handling of memory region
info into more re-usable methods.
llvm-svn: 210196
Added test stub for collecting a code, heap and stack address.
Added test to verify that the code address returns a readable,
executable memory region and that the memory region range
was indeed the one that the code belonged to.
llvm-svn: 210187
Added set-memory:{content} and get-memory-address-hex: commands
to the test exe for gdb-remote. Added a test that sets the content
via the inferior command line, then reads it back via gdb-remote
with $m.
Passing on debugserver. Marked as fail on llgs. Implementing
in the llgs branch next.
llvm-svn: 210116
- Fix Xcode project to have source files for SBTypeEnumMember.h/SBTypeEnumMember.cpp in the right place
- Rename a member variable to inluce "_sp" suffix since it is a shared pointer
- Cleanup initialization code for TypeEnumMemberImpl to not warn about out of order initialization
llvm-svn: 210051
I switched the lldb_private::FileSpec code over to use "llvm::StringRef llvm::sys::path::filename(llvm::StringRef)" for basename() and "llvm::StringRef llvm::sys::path::parent_path(llvm::StringRef)" for dirname().
<rdar://problem/16870083>
llvm-svn: 209917
Learned that MacOSX only accepts signal delivery on a thread that is
already signal handling. Reworked the test exe to cause a SIGSEGV
and recover if either nothing intercepts the SIGSEGV handler, or
if a SIGUSR1 is inserted. The test uses the latter part to test
signal delivery on continue using the SIGUSR1.
I still don't have this working on MacOSX. I'm seeing the
signal get delivered to a different thread than the one I'm
specifying with $Hc{thread-id} + $C{signo}, or with
$vCont;C{signo}:{thread-id};c. I'll come back to this
after getting it working on the llgs branch on Linux x86_64.
llvm-svn: 209912
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
Added new SocketPacketPump class to decouple gdb remote packet
reading from packet expectations code. This allowed for cleaner
implementation of the separate $O output streams (non-deterministic
packaging of inferior stdout/stderr) from all the rest of the packets.
Added a packet expectation matcher that can match expected accumulated
output with a timeout. Use a dictionary with "type":"output_match".
See lldbgdbserverutils.MatchRemoteOutputEntry for details.
Added a gdb remote test to verify that $Hc (continue thread selection)
plus signal delivery ($C{signo}) works. Having trouble getting this
to pass with debugserver on MacOSX 10.9. Tried different variants,
including $vCont;C{signo}:{thread-id};c. In some cases, I get the
test exe's signal handler to run ($vCont variant first time), in others I don't
($vCont second and further times). $C{signo} doesn't hit the signal
handler code at all in the test exe but delivers a stop. Further
$Hc and $C{signo} deliver the stop marking the wrong thread. For now I'm
marking the test as XFAIL on dsym/debugserver. Will revisit this on
lldb-dev.
Updated the text exe for these tests to support thread:print-ids (each
thread announces its thread id) and provide a SIGUSR1 thread handler
that prints out the thread id on which it was signaled.
llvm-svn: 209845
Disables exception handling in LLDB, using appropriate compiler
flags depending on the platform. This is consistent with the build
of LLVM, should improve performance, and also removes a substantial number
of warnings from the Windows build.
See http://reviews.llvm.org/D3929 for more details.
Change by Zachary Turner
llvm-svn: 209752
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
We should later rename this file (probably MIUtilSystemPOSIX), but
more clean-up is still needed here, and we can wait until we better
understand how this code may be shared between FreeBSD, Linux, and OS X.
llvm-svn: 209631
Removed a "done" TODO comment.
Moved some helper methods to the top of the unit test.
Removed some commented out code I was considering implementing
before I came up with a better overall approach.
llvm-svn: 209561
Added test to check that each thread reported by $q{f,s}ThreadInfo
can be switched to by $Hg, verified by a follow-up $qC.
Modified test exe to accept "thread:new" to create a new thread
that runs and sleeps for 5 seconds.
@llgs_test/@debugserver_test now buffer output.
llgs and debugserver gdbremote protocol tests now collect $O notification
output into the context returned from expect_lldb_gdbserver_replay.
context["O_count"] is an integer indicating the number of $O packets
collected during the replay, and context["O_content"] contains the
accumulated hex-decoded text output by the inferior (stdout and stderr).
Modified the $O check test to check the accumulated output rather than
a direct $O packet.
llvm-svn: 209560
of the symbol itself rather than forcing clients to do
it. This simplifies the logic for the expression
parser a great deal.
<rdar://problem/16935324>
llvm-svn: 209494
and sharing it with all of its FuncUnwinders, have each FuncUnwinder
create an AssemblyProfiler on demand as needed. I was worried that
the cost of creating the llvm disassemblers would be high for this
approach but it's not supposed to be an expensive operation, and it
means we don't need to add locks around this section of code.
<rdar://problem/16992332>
llvm-svn: 209493
to its unwind assembly profiler to all of the FuncUnwinders (one
per symbol) under it. If lldb is running multiple targets, you
could get two different FuncUnwinders in the same Module trying
to use the same llvm disassembler simultaneously and that may be
a re-entrancy problem.
Instead, the UnwindTable has the unwind assembly profiler and when
the FuncUnwinders want to use it, they get exclusive access to
the assembly profiler until they're done using it.
<rdar://problem/16992332>
llvm-svn: 209488
Each register returned by $qRegisterInfo is tested that it's
$p register read returns a representation that is the correct byte size
as indicated by $qRegisterInfo.
Currently enabled for debugserver, disabled for llgs.
The llgs branch will use this to verify $p implementation.
llvm-svn: 209452
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
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
Todd Fiala