| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
-Adds workaround for assertion in lldb for TestEvents.py
llvm-svn: 177116
|
| |
|
|
| |
llvm-svn: 177076
|
| |
|
|
| |
llvm-svn: 176833
|
| |
|
|
| |
llvm-svn: 176753
|
| |
|
|
|
|
|
|
| |
As much as I hate to leave this hacky code in that adds some d and q registers to ARM registers, I must leave it in.
The code is now fixed to not just assume ANY arm target will have registers in a certain order. We now verify the common regs are the same name and byte size before adding the d and q regs.
llvm-svn: 176752
|
| |
|
|
|
|
| |
Patch by Ashok Thirumurthi.
llvm-svn: 176558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DWARF with .o files now uses 40-60% less memory!
Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
- Lazily parse the debug map for each object file
- not require the address map for a .o file until debug information is linked for a .o file
llvm-svn: 176454
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
in a core file if it didn't start at the beginning of a memory segment.
I added more sophisticated kernel location code to DynamicLoaderDarwinKernel
and removed the simple one in ProcessMachCore. Unfortunately the kernel
DynamicLoader doesn't get a chance to search around in memory unless there's
a hint that this might be a kernel debug session. It was easy ot make the
kernel location code static in DynamicLoaderDarwinKernel and call it from
ProcessMachCore on the start of the session, so that's what I did.
<rdar://problem/13326647>
llvm-svn: 176405
|
| |
|
|
|
|
|
|
|
|
|
|
| |
useful,
and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since
if that does anything that requires the API lock it may deadlock against whoever is
running the Process::Destroy.
<rdar://problem/13308627>
llvm-svn: 176375
|
| |
|
|
| |
llvm-svn: 176360
|
| |
|
|
|
|
| |
KDP packets.
llvm-svn: 176319
|
| |
|
|
| |
llvm-svn: 176206
|
| |
|
|
|
|
| |
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
|
| |
|
|
|
|
| |
in the gdb-remote Process plugin files.
llvm-svn: 175947
|
| |
|
|
|
|
| |
Fixed an issue where if we got a 'A' async packet back from debugserver, we would resend the last continue command. We now correctly identify the packet as async (just like the 'O' stdout async packet) and we don't resend the continue command.
llvm-svn: 175924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
|
| |
|
|
|
|
| |
debugging a 32-bit inferior on 64-bit lldb/host.
llvm-svn: 175543
|
| |
|
|
|
|
|
|
| |
POSIX plugin
- needed due to r175241
llvm-svn: 175290
|
| |
|
|
|
|
|
|
|
| |
BreakpointSites not breakpoints, it is confusing
to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set. So don't use "software"...
llvm-svn: 175241
|
| |
|
|
|
|
| |
Poor network connections aren't handled well; commands fail instead of retrying.
llvm-svn: 175198
|
| |
|
|
|
|
| |
Rename the monitor command from "qCmd" (incorrect) to "qRcmd".
llvm-svn: 175191
|
| |
|
|
|
|
|
|
| |
inferior (on Linux)
- handle m_resume_state == eStateStopped || eStateSuspended in DoResume rather than asserting
llvm-svn: 175094
|
| |
|
|
|
|
| |
Added the ability to send monitor command to the remote GDB server with "process plugin packet monitor".
llvm-svn: 174231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enhance lldb so it can search for a kernel in memory when attaching
to a remote system. Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.
I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to
none - for environments where reading random memory can cause a
device crash
basic - look at one fixed location in memory for a kernel load address,
plus the contents of that address
fast-scan - the default, tries "basic" and then looks for the kernel's
mach header near the current pc value when lldb connects
exhaustive-scan - on 32-bit targets, step through the entire range where
the kernel can be loaded, looking for the kernel binary
I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels
appear to be working correctly with these changes.
llvm-svn: 173891
|
| |
|
|
|
|
| |
receive with an EXC_BREAKPOINT mach exception on arm.
llvm-svn: 173560
|
| |
|
|
| |
llvm-svn: 173473
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
|
| |
|
|
|
|
|
|
|
|
| |
Change the GDBRemoteRegisterContext::AddRegister function to take
its RegisterInfo argument by value instead of using a reference -
it will modify the object and modifying the contents of the
g_register_infos table in GDBRemoteRegisterContext.cpp can cause a
crash the next time we step through it.
llvm-svn: 173406
|
| |
|
|
|
|
|
|
| |
the system
handler. Also put in string translations for a couple of exceptions we were missing.
llvm-svn: 173390
|
| |
|
|
|
|
| |
be raw hex to match all other register reading and writing APIs.
llvm-svn: 173105
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify UnwindLLDB::SearchForSavedLocationForRegister so if the register
save locations for a register mid-stack is in another register (or in the
same register, indicating the reg wasn't modified in this frame), don't
return that as a found location. Keep iterating down the array of frames
until a concrete location/value for the register is found, or until we
get to frame 0 where the reg value can be used as-is.
If lldb was trying to backtrace a program that blew out its stack via
recursion and the unwind instructions had some kind of
this-reg-is-saved-in-that-reg instruction, lldb would revert to doing
a recursive search for a concrete value and blow out its own stack.
llvm-svn: 172887
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
errors (i.e. crashes) which continue to be
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
|
| |
|
|
|
|
| |
Checking in the support for doing index ids reservation when given a thread id.
llvm-svn: 171904
|
| |
|
|
|
|
|
|
| |
Python OS plug-ins now fetch thread registers lazily.
Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".
llvm-svn: 171901
|
| |
|
|
| |
llvm-svn: 171900
|
| |
|
|
| |
llvm-svn: 171864
|
| |
|
|
|
|
|
|
| |
different working directory) on Linux/FreeBSD
- fixes test case TestProcessLaunch
llvm-svn: 171854
|
| |
|
|
|
|
| |
stopping for a received signal.
llvm-svn: 171819
|
| |
|
|
| |
llvm-svn: 170800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the debugserver "qProcessInfo" implementation to return the
cpu type, cpu subtype, OS and vendor information just like qHostInfo
does so lldb can create an ArchSpec based on the returned values.
Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin
to GetHostArchitecture. If the qProcessInfo packet is supported,
GetProcessArchitecture will return the cpu type / subtype of the
process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac
system.
Have ProcessGDBRemote set the Target's architecture based on the
GetProcessArchitecture when we've completed an attach/launch/connect.
llvm-svn: 170491
|
| |
|
|
|
|
|
|
| |
- make FreeBSD ProcessMonitor API thread-ready
Patch by Matt Kopec!
llvm-svn: 170445
|
| |
|
|
|
|
| |
<rdar://problem/11597849>
llvm-svn: 170400
|
| |
|
|
|
|
| |
Patch by Matt Kopec!
llvm-svn: 170242
|
| |
|
|
| |
llvm-svn: 170224
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
|
| |
|
|
|
|
|
|
| |
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations
Patch by Matt Kopec!
llvm-svn: 169633
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like:
memory read <addr> [<end-addr>]
memory write <addr>
breakpoint set --address <addr>
disassemble --start-address <addr> --end-address <addr>
It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers.
llvm-svn: 169556
|