than being given the pthread_mutex_t from the Mutex and locks that. That allows us to
track ownership of the Mutex better.
Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)
llvm-svn: 158240
m_interrupt_sent into account. Also don't reset m_interrupt_sent in SendInterrupt but do so in SendPacketAndWaitForResponse
when we know we've handled the interrupt.
Fix a code path through ProcessGDBRemote::DoDestroy where we were tearing down the debug session but
not setting the exit status.
llvm-svn: 158043
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
Add convenience registers eax, ebx, ecx, edx, edi, esi, ebp, esp to the 'register read' command for x86_64.
Add a GDBRemoteRegisterContext::Addx86_64ConvenienceRegisters() method called from ProcessGDBRemote::BuildDynamicRegisterInfo().
Servicing of eax, for example, is accomplished by delegating to rax with an adjusted offset into the register context.
llvm-svn: 157230
that dynamically discovers remote register context information.
o GDBRemoteRegisterContext.h:
Change the prototype of HardcodeARMRegisters() to take a boolean flag, which now becomes
void
HardcodeARMRegisters(bool from_scratch);
o GDBRemoteRegisterContext.cpp:
HardcodeARMRegisters() now checks the from_scratch flag and decides whether to add composite registers to the already
existing primordial registers based on a table called g_composites which describes the composite registers.
o ProcessGDBRemote.cpp:
Modify the logic of ProcessGDBRemote::BuildDynamicRegisterInfo() to call m_register_info.HardcodeARMRegisters()
with the newly introduced 'bool from_scrach' flag.
rdar://problem/10652076
llvm-svn: 156773
Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.
Also make the selection process for auto selecting platforms based off of an arch much better.
llvm-svn: 156354
us of its architecture, use that to set the Target's arch if it
doesn't already have one set.
In Process::CompleteAttach(), if the Target has a valid arch make
sure that the Platform we pick up is compatible with that arch; if
not, find a Platform that is compatible. Don't let the the default
platform override the Target's arch.
<rdar://problem/11185420>
llvm-svn: 156116
Enable logging the packet history when registers fail to read due to not getting the sequence mutex if "--verbose" is enabled on the log channel for the "gdb-remote" log category.
This will help us track down some issues.
llvm-svn: 154704
The less locks there are, the better. I removed the thread ID mutex and now just shared the m_thread_list's mutex to make sure we don't deadlock due to lock inversion.
llvm-svn: 154652
for packet confirmation.
Also added a bit more logging.
Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state
thread so that the Process can shut down cleanly.
<rdar://problem/11228538>
llvm-svn: 154601
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
QListThreadsInStopReply
This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date.
llvm-svn: 154380
The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.
llvm-svn: 154376
The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:
virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list,
lldb_private::ThreadList &new_thread_list) = 0;
A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.
The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.
llvm-svn: 154365
<rdar://problem/11051056>
Found a race condition when sending async packets in the ProcessGDBRemote.
A little background: GDB remote clients can only send one packet at a time. You must send a packet and wait for a response. So when we continue, we obviously can't hold up the calling thread waiting for the process to stop again, so we have an async thread in the ProcessGDBRemote whose only job is to run packets that control the inferior process. When you send a continue packet, the only packet you can send is an interrupt packet (which consists of sending a CTRL+C (or a '\x03' byte)). This then stops the inferior and we can send the async packet, and then resume the target. There was a race condition that often happened during stepping where we are doing a source level single step which consists of many instruction steps and a few runs here and there when we step into a function. So the flow looks like:
inst single step
inst single step
inst single step
inst single step
inst single step
step BP and run
inst single step
inst single step
inst single step
Now if we got an async packet while the program is running we get something like:
send --> continue
send --> interrupt
recv <-- interrupt stop reply packet
send --> async packet
recv <-- async response
send --> continue again and wait for actual stop
Problems arise when this was happening when single stepping a thread where we would get:
send --> step thread 123
send --> interrupt
send --> stop reply for thread 123 (from the step)
Now we _might_ have an extra stop reply packet from the "interrupt" which we weren't checking for and we could end up with:
send --> async packet (like memory read!)
recv <-- async response (which is the interrupt stop reply packet)
Now we have the read memroy reply sitting in our buffer and waiting to be used as the reply for the next packet...
To further complicate things, the single step should have exited the async thread since the run control is finished, but now it will continue if it was interrupted.
The fixes I checked in to two major things:
- watch for the extra stop reply if we need to
- make sure we exit from the async thread run loop when the previous run control (like the instruction level single step) is finished.
Needless to say this makes very fast stepping in Xcode much more reliable.
llvm-svn: 153629
This fix really needed to happen as a previous fix I had submitted for
calculating symbol sizes made many symbols appear to have zero size since
the function that was calculating the symbol size was calling another function
that would cause the calculation to happen again. This resulted in some symbols
having zero size when they shouldn't. This could then cause infinite stack
traces and many other side affects.
llvm-svn: 152244
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself.
I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.
llvm-svn: 151476
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.
Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.
llvm-svn: 150154
will allow us to represent a process/thread ID using a pointer for the OS
plug-ins where they might want to represent the process or thread ID using
the address of the process or thread structure.
llvm-svn: 145644
1 - the DIE collections no longer have the NULL tags which saves up to 25%
of the memory on typical C++ code
2 - faster parsing by not having to run the SetDIERelations() function anymore
it is done when parsing the DWARF very efficiently.
llvm-svn: 144983
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
turned out to be unitialized data in the ProcessLaunchInfo default constructor.
Turning on MallocScribble in the environment helped track this down.
When we launch and attach using the host layer, we now inform the process that
it shouldn't detach when by calling an accessor.
llvm-svn: 144882
After recent changes we weren't reaping child processes resulting in many
zombie processes.
This was fixed by adding more settings to the ProcessLaunchOptions class
that allow clients to specify a callback function and baton to be notified
when their process dies. If one is not supplied a default callback will be
used that "does the right thing".
Cleaned up a race condition in the ProcessGDBRemote class that would attempt
to monitor when debugserver died.
Added an extra boolean to the process monitor callbacks that indicate if a
process exited or not. If your process exited with a zero exit status and no
signal, both items could be zero.
Modified the process monitor functions to not require a callback function
in order to reap the child process.
llvm-svn: 144780
on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. Also all of the argument,
envronment and stdio things are now handled in a much more centralized fashion.
llvm-svn: 143656
lldb_private::Error objects the rules are:
- short strings that don't start with a capitol letter unless the name is a
class or anything else that is always capitolized
- no trailing newline character
- should be one line if possible
Implemented a first pass at adding "--gdb-format" support to anything that
accepts format with optional size/count.
llvm-svn: 142999
process IDs, and thread IDs, but was mainly needed for for the UserID's for
Types so that DWARF with debug map can work flawlessly. With DWARF in .o files
the type ID was the DIE offset in the DWARF for the .o file which is not
unique across all .o files, so now the SymbolFileDWARFDebugMap class will
make the .o file index part (the high 32 bits) of the unique type identifier
so it can uniquely identify the types.
llvm-svn: 142534
a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee
encapsulated by SBValue (WatchPointee).
Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that.
Modified the watchpoint related test suite to reflect the change.
Plus replacing WatchpointLocation with Watchpoint throughout the code base.
There are still cleanups to be dome. This patch passes the whole test suite.
Check it in so that we aggressively catch regressions.
llvm-svn: 141925
set up yet, if we're talking to an Apple arm device set the register set based on the
arm device's attributes; this is a safe assumption to make in this particular environment.
llvm-svn: 141265
symbol context that represents an inlined function. This function has been
renamed internally to:
bool
SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc,
SymbolContext &next_frame_sc,
Address &next_frame_pc) const;
And externally to:
SBSymbolContext
SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc,
SBAddress &parent_frame_addr) const;
The correct blocks are now correctly calculated.
Switched the stack backtracing engine (in StackFrameList) and the address
context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...)
so all inlined callstacks will match exactly.
llvm-svn: 140910
etc to specific source files.
Added SB API's to specify these source files & also more than one module.
Added an "exact" option to CompileUnit's FindLineEntry API.
llvm-svn: 140362
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.
llvm-svn: 140185
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
