rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
if (!DNBProcessInterrupt(m_ctx.ProcessID()))
HandlePacket_last_signal (NULL);
return rnb_success;
}
In the call to DNBProcessInterrupt we did:
nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
MachProcessSP procSP;
if (GetProcessSP (pid, procSP))
return procSP->Interrupt();
return false;
}
This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.
To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets.
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.
The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)
Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...
As time goes on we should add more packet validators.
<rdar://problem/22859505>
llvm-svn: 265086
previous release. Most of the diffs are duplication in the xcode
project file caused by adding a "debugserver-mini" target. Jim
Ingham added support for a new SPI needed to request app launches
on iOS. Greg Clayton added code to indicate the platform of the
binary (macosx, ios, watchos, tvos) based on Mach-O load commands.
Jason Molenda added code so debugserver will identify when it is
running on a tvos/watchos device to lldb.
llvm-svn: 251091
Summary:
Add dependencies to the custom commands so that they get
re-executed as needed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13580
llvm-svn: 249860
debugserver to match. "gcc" is now "ehframe" and "gdb" is now
"debugserver". Because this is debugserver, what we call the Process
Plugin register numbers up in lldb are the debugserver register
numbers down here - they are the register numbers that debugserver
will use to refer to these registers over the gdb-remote protocol.
debugserver was already reporting the registers with the key
"ehframe"; this change is just cleaning up the internal variable
names to match.
llvm-svn: 247751
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
Summary:
Comparing m_page_size against kInvalidPageSize was resulting in
a warning about comparing integers with different signs. Since
kInvalidPageSize isn't used anywhere outside of MachVMMemory.cpp,
we can readily transform it into a static const vm_size_t with
the correct value to avoid the sign comparison warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12519
llvm-svn: 246606
Older OSX versions don't define NSOperatingSystemVersion, so building
lldb gets: error: unknown type name 'NSOperatingSystemVersion'
This patch fixes the build by having GetOSVersionNumbers return false if
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101000, causing lldb to
behave the same as it did before the commit.
Reviewed by: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12396
llvm-svn: 246138
Summary:
This was no longer needed and hasn't been needed since r143244
in 2011. This removes everything associated with generating
or using it.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11971
llvm-svn: 244850
major, minor, and patchlevel in the qHostInfo reply.
Document that qHostInfo may report major/minor/patch
separately / in addition to the version: combination.
<rdar://problem/22125465>
llvm-svn: 244716
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
Summary:
No longer rely on cmake to set DEBUGSERVER_VERSION_STR,
but now generate the _vers.c file like xcode does
and include the generated file into the build on Mac OS X.
This fixes the cmake Mac OS X build after an earlier change
by Jason Molenda.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11450
llvm-svn: 243072
Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread.
Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops.
llvm-svn: 242593
vm_kernel_page_size appears to not be defined on OSX Mavericks, so the
build fails. This patch fixes the build by calculating the pagesize if
_VM_PAGE_SIZE_H_ is not defined.
llvm-svn: 242114
jGetLoadedDynamicLibrariesInfos. This packet is similar to
qXfer:libraries:read except that lldb supplies the number of solibs
that should be reported about, and the start address for the list
of them. At the initial process launch we'll read the full list
of solibs linked by the process -- at this point we could be using
qXfer:libraries:read -- but on subsequence solib-loaded notifications,
we'll be fetching a smaller number of solibs, often only one or two.
A typical Mac/iOS GUI app may have a couple hundred different
solibs loaded - doing all of the loads via memory reads takes
a couple of megabytes of traffic between lldb and debugserver.
Having debugserver summarize the load addresses of all the solibs
and sending it in JSON requires a couple of hundred kilobytes
of traffic. It's a significant performance improvement when
communicating over a slower channel.
This patch leaves all of the logic for loading the libraries
in DynamicLoaderMacOSXDYLD -- it only call over ot ProcesGDBRemote
to get the JSON result.
If the jGetLoadedDynamicLibrariesInfos packet is not implemented,
the normal technique of using memory read packets to get all of
the details from the target will be used.
<rdar://problem/21007465>
llvm-svn: 241964
the register state when debugging AArch32 programs (armv7
programs running on an armv8 processor). Most notably,
there is no "fpscr" register in the register context -
there is an fpsr and an fpcr.
Also fix a bug where the floating point values could not
be written in armv7 processes.
<rdar://problem/18977767>
llvm-svn: 226244
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
This patch fixes the codesigning of debugserver on OSX when built with
cmake. Without this you get this error when debugging:
error: process launch failed: unable to locate debugserver
Note: you also need to set LLDB_DEBUGSERVER_PATH to point to your built debugserver.
e.g. export LLDB_DEBUGSERVER_PATH=`pwd`/bin/debugserver
Change by dawn@burble.org.
Tested on MacOSX 10.9.5 and Xcode 6.1 Beta using cmake/ninja.
Verified no build break on Linux Ubuntu cmake/ninja and Xcode 6.1 canonical build.
llvm-svn: 218890
to the remote side (QStartNoAckMode) - it may take a little longer
than normal to get a reply.
In debugserver, hardcode the priority for several threads so they
aren't de-prioritized when a user app is using system resources.
Also, set the names of the threads.
<rdar://problem/17509866>
llvm-svn: 213828
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
Building OS X debugserver assumes you have an Xcode installation at /Application/Xcode.app. Let's instead detect where Xcode is using xcrun.
See http://reviews.llvm.org/D4152
llvm-svn: 211074
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
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
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
This change does the following:
* Adds Makefile build scripts to debug server.
* Fixes a few small mistakes in the other makefiles.
* Modifies generate-vers.pl slightly to also work for debugserver.
* Changes the OS X, non-framework python search path from libdir to
libdir/python2.X/site-packages where it is installed by the build
system (also where it is installed on other operating systems).
Patch by Keno Fischer.
llvm-svn: 199543
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".
"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.
All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.
Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction.
Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).
Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.
llvm-svn: 194621
- removed all gaps from the g/G packets
- optimized registers for x86_64 to not send/receive xmm0-xmm15 as well as ymm0-ymm15, now we only send ymm0-15 and xmm0-15 are now pseudo regs
- Fixed x86_64 floating point register gaps
- Fixed x86_64 so that xmm8-xmm15 don't overlap with ymm0-ymm3. This could lead to bad values showing in the debugger and was due to bad register info structure contents
- Fixed i386 so we only send ymm0-ymm7 and xmm0-xmm7 are now pseudo regs.
- Fixed ARM register definitions to not have any gaps
- Fixed it so value registers and invalidation registers are specified using register names which avoid games we had to play with register numbering in the ARM plugin.
llvm-svn: 194302
- updated RNBDefs.h to allow version numbers to be passed in via preprocessor defines
- update libdebugserver.cpp to compile against latest DNBProcessKill signature
Review: http://llvm-reviews.chandlerc.com/D1331
llvm-svn: 188078
take for threads created while the program is running. Remove the testcase skips from TestConcurrentEvents.py,
since they all pass now, and fix TestWatchpointMultipleThreads.py - which should have caught this problem -
so it doesn't artificially break on new thread creation before the watchpoint triggers.
llvm.org/pr16566
<rdar://problem/14383244>
llvm-svn: 186132
Found a race condition when killing an application where the state could be set to exited by the waitpid_thread() _before_ we call task resume (via MachProcess::PrivateResume()) in MachProcess::Kill().
llvm-svn: 185048
Match up with top’s implementation on recent Cab as API has changed a bit.
Tested the same binary running on Zin as well. Tested ARM binary on iOS as well.
llvm-svn: 185017
support files for debugserver to fix a build failure for arm. Also
remove some of the code used for software-driven single instruction
stepping; this is slowly being yanked out and these particular bits
overlap with the nub_break_t going away.
llvm-svn: 184828
325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.
That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.
Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.
llvm-svn: 183820
Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().
llvm-svn: 181080
if we have an updated task_info call available; else fall back to getting
the default host-wide page size.
Update all uses of the vm page size to get it via MachVMMemory::PageSize().
<rdar://problem/13477763>, <rdar://problem/13498504>
llvm-svn: 178953
Try and reap process when sending the "k" packet to avoid a race condition. We now wait for at most 1 second to reap the child process that we are killing.
llvm-svn: 178726
number in RNBRemote::HandlePacket_qProcessInfo -- add a new
GetCurrentThreadMachPort() so callers who need to make a mach
thred_get_state() call at the RNBRemote level will have a way to
get the port number.
llvm-svn: 178619
Added logging that will show up in the system console when we try to resume a process that is already running, or has an unexpected state.
llvm-svn: 176960
Drop the old f registers from debugserver's register list. Add the
NEON 128-bit q registers to debugserver, support reading and writing.
Add the new contains / invalidates mappings for the s, d, and q
registers so lldb will know what registers overlay what other registers.
Change the default format of s and d registers to be floating point
instead of hex. Remove some UTF-8 hyphen chars in comments in the ARM
register number definition headers.
<rdar://problem/13121797>
llvm-svn: 176915
Make it configurable what to profile.
For Mac, we don't use the dirty page size yet and hence there is no need to gather that. This should be way better in not draining the battery since we are operating between 0% to 0.1% on the Mac after this change.
llvm-svn: 176451
own port namepsace) as the thread identifier to using the system-wide
globally unique thread id as the thread identifier number.
MachThread.cpp keeps both the unique id and the mach port number
for each thread. All layers outside MachThread class use the unique
id with three exceptions: (1) Mach exceptions come in with the port
number (thread_port) which needs to be translated, (2) any calls to
low-level thread_get_state/thread_set_state/thread_suspend etc need
to use the mach port number, (3) MachThreadList::UpdateThreadList
which creates the MachThread objects gets the unique id and passes
it to the MachThread ctor as an argument.
In general, any time nub_thread_t is used, it is now referring to a
unique thread id. Any time a thread_t is used, it is now referring
to a mach port number. There was some interchangability of these
types previously. nub_thread_t has also been changed to a 64-bit
type which necessitated some printf specification string changes.
I haven't been able to test these changes extensively yet but want
to checkpoint the work. The scenarios I've been testing are all
working correctly so while there may be some corner cases I haven't
hit yet, I think it is substantially correct.
<rdar://problem/12931414>
llvm-svn: 175870
Fixed the 32, 16, and 8 bit pseudo regs for x86_64 (real reg of "rax" which subvalues "eax", "ax", etc...) to correctly get updated when stepping. Also fixed it so actual registers can specify what other registers must be invalidated when a register is modified. Previously, only pseudo registers could invalidate other registers.
Modified the LLDB qRegisterInfo extension to the GDB remote interface to support specifying the containing registers with the new "container-regs" key whose value is a comma separated list of register numbers. Also added a "invalidate-regs" key whose value is also a comma separated list of register numbers.
Removed the hack GDBRemoteDynamicRegisterInfo::Addx86_64ConvenienceRegisters() function and modified "debugserver" to specify the registers correctly using the new "container-regs" and "invalidate-regs" keys.
llvm-svn: 173096
Swap in index ids for thread ids in GDBRemoteCommunicationClient. Besides dealing with the async logic, I have to take care of the situation when the inferior paused as well.
llvm-svn: 172869
Prevent profiling from working on older debugserver. Just a simple renaming since the caller is prepared to handle the ‘unimplemented’ answer.
llvm-svn: 172583
1. Using mach port number, just like when inferior is paused.
2. Use key:value pair of thread used time instead of comma separated notation.
llvm-svn: 172012
Add unconditional logging messages to every place in debugserver
where we send a SIGKILL signal or do a ptrace PT_KILL call to
terminate the inferior process. When the debuggee is silently
killed off, the console logging from debugserver can disambiguate
whether debugserver killed off the process because it failed to
completely set it up, becuase it was told to (via the "k" packet),
or if some external daemon killed it.
llvm-svn: 171606
Prevent async and sync calls to get profile data from stomping on each other.
At the same time, don't use '$' as end delimiter per chunk of profile data.
llvm-svn: 168948
calling functions. This is necessary on Mac OS X, since bad things can happen if you set
the registers of a thread that's sitting in a kernel trap.
<rdar://problem/11145013>
llvm-svn: 160756
Designate MachThreadList as a transaction coordinator when doing Enable/DisableHardwareWatchpoint on the list of threads.
In case the operation (iterating on the threads and doing enable/disable) fails in the middle, we rollback the already
enabled/disabled threads to their checkpointed states. When all the threads succeed in enable/disable, we ask each thread
to finsih the transaction and commit the change of the debug state.
llvm-svn: 157858
Add default Process::GetWatchpointSupportInfo() impl which returns an error of "not supported".
Add "qWatchpointSupportInfo" packet to the gdb communication layer to support this, and modify TestWatchpointCommands.py to test it.
llvm-svn: 157345
We do this by delegating to two available Watchpoint Register Pairs (wvr, wcr). With
each pair handling the 4 bytes of (uint64_t)variable.
llvm-svn: 153300
that the inferior cannot execute past the watchpoint-triggering instruction.
The solution is disable the watchpoint before resuming the inferior and make it hardware single step;
when the inferior stops again due to single step, re-enable the watchpoint and disable the single step
to make the inferior able to continue again without obstacle.
rdar://problem/9667960
llvm-svn: 153273
However, the debugserver cannot get past the instruction which triggered the watchpoint.
So a workaround is in place for the time being which disables the triggered watchpoint
before resuming.
Lots of commented out printf's remain in the source which needs to be cleaned up.
WIP rdar://problem/9667960
llvm-svn: 153228
On darwin, if child process of process being debugged dies due to mach exception, the debugged process will die.
debugserver now only handles the mach exceptions for the task being debugged.
llvm-svn: 152291
Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr).
llvm-svn: 152102
We will return a valid range when possible and omit the "permissions" key
when the memory is not readable, writeable or executeable. This will help us
know the difference between an error back from this packet and unsupported,
from just "this address isn't in a valid region".
llvm-svn: 146394
from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:
virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);
virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);
Only the first one needs to be implemented by subclasses that can add this
support.
Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.
llvm-svn: 144976
Add a more general purpose qMemoryRegionInfo packet which can
describe various attributes about a memory region. Currently it
will return the start address, size, and permissions (read, write,
executable) for the memory region. It may be possible to add
additional attributes in the future such as whether the region is
designated as stack memory or jitted code a la vmmap.
I still haven't implemented the lldb side of the code to use this
packet yet so there may be unexpected behavior - but the basic implementation looks
about right. I'll hook it up to lldb soon and fix any problems that crop up.
llvm-svn: 144175
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.
I want to have this feature available for the unwinder code. When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --
is the current pc value in an executable region (e.g. did they
jump to unallocated/unexecutable memory? we know how to unwind
from here if so.)
Is the stack pointer or the frame pointer the correct register
to use to find the caller's saved pc value?
Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.
llvm-svn: 144074
- If you download and build the sources in the Xcode project, x86_64 builds
by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
Xcode project will download the right LLVM sources and build them from
scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
directory, we will use the sources you have placed in the LLDB directory.
Python can now be disabled for platforms that don't support it.
Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.
llvm-svn: 143678
then we spawn child processes (debugserver, etc) and those bad settings get
inherited. We stop this from happening by correctly mucking with the posix
spawn attributes.
llvm-svn: 143176
the watchpoint state is changed, not only does the change propagate to all the thread instances,
it also updates a global debug state, if chosen by the DNBArchProtocol derivative.
Once implemented, the DNBArchProtocol derivative, also makes sure that when new thread comes along,
it tries to inherit from the global debug state, if it is valid.
Modify TestWatchpointMultipleThreads.py to test this functionality.
llvm-svn: 140811
it enables the hardware watchpoint for all existing threads. Add a test file for that.
Also fix MachThreadList::DisableHardwareWatchpoint().
llvm-svn: 140757
We had some cases where getting the shared pointer for a module from
the global module list was causing a performance issue when debugging
with DWARF in .o files. Now that the module uses intrusive ref counts,
we can easily convert any pointer to a shared pointer.
llvm-svn: 139983
data sent back to the debugger. On the debugger side, use the opportunity during the
StopInfoMachException::CreateStopReasonWithMachException() method to set the hardware index
for the very watchpoint location.
llvm-svn: 139975
the passed in (MachException::Data &)exc first before possible reassignment of the
member m_stop_exception with exc. This allows lldb to stop at the watchpoint of
a simple test program.
llvm-svn: 139767
o WatchpointLocationList:
Add a GetListMutex() method.
o WatchpointLocation:
Fix Dump() method where there was an extra % in the format string.
o Target.cpp:
Add implementation to CreateWatchpointLocation() to create and enable a watchpoint.
o DNBArchImplX86_64.cpp:
Fix bugs in SetWatchpoint()/ClearWatchpoint() where '==' was used, instead of '=',
to assign/reset the data break address to a debug register.
Also fix bugs where a by reference debug_state should have been used, not by value.
llvm-svn: 139666
in order to distinguish the real single step exception from a watchpoint exception
which uses the same exc_type of EXC_BREAKPOINT and exc_code of EXC_I386_SGL.
This is done by checking the debug status register to find out whether the watchpoint
data break event has fired, and, if yes, stuff the data break address into the exception's
exc_sub_code field on the debugserver side for lldb to consume on the other end.
llvm-svn: 139274
(MachThreadList::EnableHardwareWatchpoint()) where the watchpoint is not associated
with a thread and the current thread, if set, is returned, otherwise we return the
first thread.
Plus minor change to RNBRemote::HandlePacket_z() to use the existing macros to check
the validity of break_id/watch_id.
llvm-svn: 139246
Add a virtual method GetHardwareWatchpointHit() to the DNBArchProtocol base class
which consults the architecture to return the watchpoint hit; otherwise return an
invalid index.
Add impl. of the method to X86_64 and I386 subclasses, plus reset the debug status
register before we resume execution of the inferior thread.
llvm-svn: 139034
cpu registers it uses and it crashes the release version of
debugserver. We just get lucky in Debug builds. Until this
is fixed I am disabling AVX detection to avoid the crashes.
llvm-svn: 137113
fixed a few bugs that revealed. Now the "register
read" command should show AVX registers
(ymm0-ymm15) on Mac OS X platforms that support
them.
When testing this on Mac OS X, run debugserver
manually, like this:
debugserver --native-regs localhost:1111 /path/to/executable
Then
lldb /path/to/executable
...
(lldb) process connect connect://localhost:1111
llvm-svn: 135331
with the "target modules lookup --address <addr>" command. The variable
ID's, names, types, location for the address, and declaration is
displayed.
This can really help with crash logs since we get, on MacOSX at least,
the registers for the thread that crashed so it is often possible to
figure out some of the variable contents.
llvm-svn: 134886
parse NOP instructions. I added the new table entries for the NOP for the
plain NOP, Yield, WFE, WFI, and SEV variants. Modified the opcode emulation
function EmulateInstructionARM::EmulateMOVRdSP(...) to notify us when it is
creating a frame. Also added an abtract way to detect the frame pointer
register for both the standard ARM ABI and for Darwin.
Fixed GDBRemoteRegisterContext::WriteAllRegisterValues(...) to correctly be
able to individually write register values back if case the 'G' packet is
not implemented or returns an error.
Modified the StopInfoMachException to "trace" stop reasons. On ARM we currently
use the BVR/BCR register pairs to say "stop when the PC is not equal to the
current PC value", and this results in a EXC_BREAKPOINT mach exception that
has 0x102 in the code.
Modified debugserver to create the short option string from long option
definitions to make sure it doesn't get out of date. The short option string
was missing many of the newer short option values due to a modification of
the long options defs, and not modifying the short option string.
llvm-svn: 131911
of duplicated code from appearing all over LLDB:
lldb::addr_t
Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error);
bool
Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error);
size_t
Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error);
size_t
Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error);
in lldb_private::Process the following functions were renamed:
From:
uint64_t
Process::ReadUnsignedInteger (lldb::addr_t load_addr,
size_t byte_size,
Error &error);
To:
uint64_t
Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr,
size_t byte_size,
uint64_t fail_value,
Error &error);
Cleaned up a lot of code that was manually doing what the above functions do
to use the functions listed above.
Added the ability to get a scalar value as a buffer that can be written down
to a process (byte swapping the Scalar value if needed):
uint32_t
Scalar::GetAsMemoryData (void *dst,
uint32_t dst_len,
lldb::ByteOrder dst_byte_order,
Error &error) const;
The "dst_len" can be smaller that the size of the scalar and the least
significant bytes will be written. "dst_len" can also be larger and the
most significant bytes will be padded with zeroes.
Centralized the code that adds or removes address bits for callable and opcode
addresses into lldb_private::Target:
lldb::addr_t
Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;
lldb::addr_t
Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;
All necessary lldb_private::Address functions now use the target versions so
changes should only need to happen in one place if anything needs updating.
Fixed up a lot of places that were calling :
addr_t
Address::GetLoadAddress(Target*);
to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress()
as needed. There were many places in the breakpoint code where things could
go wrong for ARM if these weren't used.
llvm-svn: 131878
and set the address as an opcode address or as a callable address. This is
needed in various places in the thread plans to make sure that addresses that
might be found in symbols or runtime might already have extra bits set (ARM/Thumb).
The new functions are:
bool
Address::SetCallableLoadAddress (lldb::addr_t load_addr, Target *target);
bool
Address::SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target);
SetCallableLoadAddress will initialize a section offset address if it can,
and if so it might possibly set some bits in the address to make the address
callable (bit zero might get set for ARM for Thumb functions).
SetOpcodeLoadAddress will initialize a section offset address using the
specified target and it will strip any special address bits if needed
depending on the target.
Fixed the ABIMacOSX_arm::GetArgumentValues() function to require arguments
1-4 to be in the needed registers (previously this would incorrectly fallback
to the stack) and return false if unable to get the register values. The
function was also modified to first look for the generic argument registers
and then fall back to finding the registers by name.
Fixed the objective trampoline handler to use the new Address::SetOpcodeLoadAddress
function when needed to avoid address mismatches when trying to complete
steps into objective C methods. Make similar fixes inside the
AppleThreadPlanStepThroughObjCTrampoline::ShouldStop() function.
Modified ProcessGDBRemote::BuildDynamicRegisterInfo(...) to be able to deal with
the new generic argument registers.
Modified RNBRemote::HandlePacket_qRegisterInfo() to handle the new generic
argument registers on the debugserver side.
Modified DNBArchMachARM::NumSupportedHardwareBreakpoints() to be able to
detect how many hardware breakpoint registers there are using a darwin sysctl.
Did the same for hardware watchpoints in
DNBArchMachARM::NumSupportedHardwareWatchpoints().
llvm-svn: 131834
Greg Clayton