| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
llvm-svn: 150871
|
|
|
|
|
|
|
| |
register set where it could get an error when trying to restore the
fake "f0" - "f7" 12 byte float regs.
llvm-svn: 150781
|
|
|
|
|
|
|
|
| |
otherwise we will have a launched process stopped at the entry point and
it will get reparented when debugserver goes away and we won't be able to
kill the process later.
llvm-svn: 149622
|
|
|
|
| |
llvm-svn: 149171
|
|
|
|
| |
llvm-svn: 149168
|
|
|
|
|
|
| |
shell script build phase.
llvm-svn: 149165
|
|
|
|
| |
llvm-svn: 148613
|
|
|
|
| |
llvm-svn: 148202
|
|
|
|
| |
llvm-svn: 148098
|
|
|
|
| |
llvm-svn: 148018
|
|
|
|
|
|
| |
It is incomplete and untested; passes the compilation only.
llvm-svn: 147901
|
|
|
|
|
|
| |
stepping.
llvm-svn: 147886
|
|
|
|
|
|
| |
<rdar://problem/10568492>
llvm-svn: 147883
|
|
|
|
| |
llvm-svn: 147865
|
|
|
|
| |
llvm-svn: 147794
|
|
|
|
|
|
| |
comma at end of enumerator list
llvm-svn: 147633
|
|
|
|
| |
llvm-svn: 147597
|
|
|
|
| |
llvm-svn: 147193
|
|
|
|
| |
llvm-svn: 147061
|
|
|
|
| |
llvm-svn: 146978
|
|
|
|
|
|
| |
and debugserver-156.
llvm-svn: 146808
|
|
|
|
| |
llvm-svn: 146643
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 146271
|
|
|
|
| |
llvm-svn: 146198
|
|
|
|
|
|
| |
Fixed detection of AVX on darwin now that our kernel supports it.
llvm-svn: 146135
|
|
|
|
|
|
| |
class scoping in DumpDBGState()'s definiton.
llvm-svn: 146128
|
|
|
|
| |
llvm-svn: 145978
|
|
|
|
| |
llvm-svn: 145528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 144911
|
|
|
|
| |
llvm-svn: 144616
|
|
|
|
| |
llvm-svn: 144200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 144032
|
|
|
|
|
|
|
| |
in "/System/Library/PrivateFrameworks", and also have "lldb" in the Xcode.app
and the LLDB.framework in Xcode.app as well.
llvm-svn: 144030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
llvm-svn: 143587
|
|
|
|
| |
llvm-svn: 143408
|
|
|
|
|
|
|
| |
the path to the /Developer directory, and also bumped the Xcode project version
for lldb-83 and debugserver-148.
llvm-svn: 143269
|
|
|
|
|
|
| |
the ensuing mayhem.
llvm-svn: 143244
|
|
|
|
|
|
| |
submitted.
llvm-svn: 143199
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 142753
|
|
|
|
| |
llvm-svn: 142718
|
|
|
|
| |
llvm-svn: 140922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DNBArchProtocol so that when
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
|
|
|
|
|
|
|
|
|
| |
impl so that
it enables the hardware watchpoint for all existing threads. Add a test file for that.
Also fix MachThreadList::DisableHardwareWatchpoint().
llvm-svn: 140757
|
|
|
|
|
|
| |
Patch by Filipe.
llvm-svn: 140037
|