Issue discovered during the GSoC 2014 project implementing FreeBSD
kernel support. The existing elf-core Process plugin crashed trying
to read from /dev/mem (the kernel memory device).
Patch by Mike Ma.
llvm-svn: 211102
RegisterSets are assumed to be terminated by this value. Loops over
register set values would fail without LLDB_INVALID_REGNUM terminating
the list. This change adjusts the static check to account for the
size of the register set regnum list being one larger than the expected
valid register set count.
llvm-svn: 210964
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
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
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
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
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
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
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
$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
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
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
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
When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro. This is a standard macro, defined in stddef.h. Include
this header to ensure that offsetof is declared.
llvm-svn: 206702
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
As the Linux PTRACE_KILL behaviour is not used by LLDB, rename
BringProcessIntoLimbo to Kill, and change the implementation to simply
call kill() instead of using ptrace.
Thanks to Todd F for testing (Ubuntu 12.04, gcc 4.8.2).
Sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3159
llvm-svn: 205337
Store the gpr data in a DataBufferHeap and use a DataExtractor to
extract register values with appropriate endianness. This avoids hard-
coding the register count, and with some further work would allow this
class to provide generic register context storage for any CPU.
llvm-svn: 205329
On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
For now I'm committing only the FreeBSD change, until the Linux change
(review D3159) is successfully tested.
http://llvm.org/pr18894
llvm-svn: 205315
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
condition where we could end up killing debugserver (and thus the target) before it had a chance
to detach.
Also fix debugserver to send the OK AFTER it detaches to avoid the same race condition.
<rdar://problem/16202713>
llvm-svn: 205043
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
