| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
takes separate file handles for stdin, stdout, and stder and also allows for
the working directory to be specified.
Added support to "process launch" to a new option: --working-dir=PATH. We
can now set the working directory. If this is not set, it defaults to that
of the process that has LLDB loaded. Added the working directory to the
host LaunchInNewTerminal function to allows the current working directory
to be set in processes that are spawned in their own terminal. Also hooked this
up to the lldb_private::Process and all mac plug-ins. The linux plug-in had its
API changed, but nothing is making use of it yet. Modfied "debugserver" and
"darwin-debug" to also handle the current working directory options and modified
the code in LLDB that spawns these tools to pass the info along.
Fixed ProcessGDBRemote to properly pass along all file handles for stdin, stdout
and stderr.
After clearing the default values for the stdin/out/err file handles for
process to be NULL, we had a crasher in UserSettingsController::UpdateStringVariable
which is now fixed. Also fixed the setting of boolean values to be able to
be set as "true", "yes", "on", "1" for true (case insensitive) and "false", "no",
"off", or "0" for false.
Fixed debugserver to properly handle files for STDIN, STDOUT and STDERR that are not
already opened. Previous to this fix debugserver would only correctly open and dupe
file handles for the slave side of a pseudo terminal. It now correctly handles
getting STDIN for the inferior from a file, and spitting STDOUT and STDERR out to
files. Also made sure the file handles were correctly opened with the NOCTTY flag
for terminals.
llvm-svn: 124060
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checking the validity of the shared pointer prior to using it.
Fixed the GDB remote plug-in to once again watch for a reply from the "k"
packet, and fixed the logic to make sure the thread requesting the kill
and the async thread play nice (and very quickly) by synchronizing the
packet sending and reply. I also tweaked some of the shut down packet
("k" kill, "D" detach, and the halt packet) to make sure they do the right
thing.
Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass
the timeout along to WaitForStateChangedEventsPrivate() and made the function
behave correctly with respect to timing out.
Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added
the start of being able to set the working directory for the inferior process.
llvm-svn: 124049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
threads that we spawn let us know when they are going away and that we
don't timeout waiting for a message from threads that have gone away.
We also now don't expect the "k" packet (kill) to send a response. This
greatly speeds up debugger shutdown performance. The test suite now runs
quite a bit faster.
Added a fix to the variable display code that fixes the display of
base classes. We were assuming the virtual or normal base class offsets
were being given in bit sizes, but they were being given as character
sizes, so we needed to multiply the offset by 8. This wasn't affecting
the expression parser, but it was affecting the correct display of C++
class base classes and all of their children.
llvm-svn: 124024
|
| |
|
|
|
|
|
|
|
|
| |
turn it on when
we are requesting a single thread to run. May seem like a silly thing to do, but the kernel
on MacOS X will inject new threads into a program willy-nilly, and I would like to keep them
from running if I can.
llvm-svn: 124018
|
| |
|
|
|
|
|
|
|
|
|
| |
while the inferior is running) to be fast. The previous code would always
cause the sender to timeout, yet still return success due to the way we
were waiting for a value (incorrect value) to change. Now the ProcessGDBRemote
plug-in has a public and private "is running" predicate. This allows things
that need to send async packets to interrupt and wait for the private "is running"
state to be flipped to false, and then resume quickly with no timeout.
llvm-svn: 123903
|
| |
|
|
|
|
|
| |
Set the thread state to "bland" before calling functions so they don't
inherit the pending signals and die.
llvm-svn: 123869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.
llvm-svn: 123762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by LLDB. Instead of being materialized into the input structure
passed to the expression, variables are left in place and pointers
to them are materialzied into the structure. Variables not resident
in memory (notably, registers) get temporary memory regions allocated
for them.
Persistent variables are the most complex part of this, because they
are made in various ways and there are different expectations about
their lifetime. Persistent variables now have flags indicating their
status and what the expectations for longevity are. They can be
marked as residing in target memory permanently -- this is the
default for result variables from expressions entered on the command
line and for explicitly declared persistent variables (but more on
that below). Other result variables have their memory freed.
Some major improvements resulting from this include being able to
properly take the address of variables, better and cleaner support
for functions that return references, and cleaner C++ support in
general. One problem that remains is the problem of explicitly
declared persistent variables; I have not yet implemented the code
that makes references to them into indirect references, so currently
materialization and dematerialization of these variables is broken.
llvm-svn: 123371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a method:
void RegisterContext::InvalidateIfNeeded (bool force);
Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache
when it doesn't need to be.
Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
these before and it was causing us to read at least three registers every
time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
info. Prior to this fix we would continually send a qThreadStopInfo packet
over and over when any thread stop info was requested. We now note the stop
ID that the stop info was requested for and avoid multiple requests.
Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.
Fixed an bug in the ValueObject code that would cause children to not be
displayed.
llvm-svn: 123127
|
| |
|
|
|
|
| |
Thanks Bruce!
llvm-svn: 123083
|
| |
|
|
|
|
|
|
|
|
| |
new "hexname" key for the "key:value;" duple that is part of the packet. This
allows for thread names to contain special characters such as $ # : ; + -
Debugserver now detects if the thread name contains special characters and
sends the chars in hex format if needed.
llvm-svn: 123053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
|
| |
|
|
| |
llvm-svn: 122059
|
| |
|
|
|
|
| |
would eventually destroy the dynamic loader (when the lldb_private::Process::m_dynamic_loader_ap destroys itself in the object member destructor chain). The dynamic loader was calling a pure virtual method in Process which was causing a crash. The quick fix is to reset the auto pointer in the ProcessGDBRemote destructor when ProcessGDBRemote is still a valid object with all its pure virtual functions intact.
llvm-svn: 121704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have children sections).
Modified SectionLoadList to do it's own multi-threaded protected on its map.
The ThreadSafeSTLMap class was difficult to deal with and wasn't providing
much utility, it was only getting in the way.
Make sure when the communication read thread is about to exit, it clears the
thread in the main class.
Fixed the ModuleList to correctly ignore architectures and UUIDs if they aren't
valid when searching for a matching module. If we specified a file with no arch,
and then modified the file and loaded it again, it would not match on subsequent
searches if the arch was invalid since it would compare an invalid architecture
to the one that was found or selected within the shared library or executable.
This was causing stale modules to stay around in the global module list when they
should have been removed.
Removed deprecated functions from the DynamicLoaderMacOSXDYLD class.
Modified "ProcessGDBRemote::IsAlive" to check if we are connected to a gdb
server and also make sure our process hasn't exited.
llvm-svn: 121236
|
| |
|
|
|
|
|
|
|
|
| |
do. Closing on EOF is an option that can be set on the
lldb_private::Communication or the lldb::SBCommunication objects after they
are created. Of course the EOF support isn't hooked up, so they don't do
anything at the moment, but they are left in so when the code is fixed, it
will be easy to get working again.
llvm-svn: 120885
|
| |
|
|
|
|
|
|
|
|
| |
inferior to be launched without setting up terminal stdin/stdout for it
(leaving the lldb command line accessible while the program is executing).
Also add a user settings variable, 'target.process.disable-stdio' to allow
the user to set this globally rather than having to use the command option
each time the process is launched.
llvm-svn: 120825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an error saying the resume timed out. Previously the thread that was trying
to resume the process would eventually call ProcessGDBRemote::DoResume() which
would broadcast an event over to the async GDB remote thread which would sent the
continue packet to the remote gdb server. Right after this was sent, it would
set a predicate boolean value (protected by a mutex and condition) and then the
thread that issued the ProcessGDBRemote::DoResume() would then wait for that
condition variable to be set. If the async gdb thread was too quick though, the
predicate boolean value could have been set to true and back to false by the
time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean
value. So we can't use the predicate value as a handshake. I have changed the code
over to using a Event by having the GDB remote communication object post an
event:
GDBRemoteCommunication::eBroadcastBitRunPacketSent
This allows reliable handshaking between the two threads and avoids the erroneous
ProcessGDBRemote::DoResume() errors.
Added a host backtrace service to allow in process backtraces when trying to track
down tricky issues. I need to see if LLVM has any backtracing abilities abstracted
in it already, and if so, use that, but I needed something ASAP for the current issue
I was working on. The static function is:
void
Host::Backtrace (Stream &strm, uint32_t max_frames);
And it will backtrace at most "max_frames" frames for the current thread and can be
used with any of the Stream subclasses for logging.
llvm-svn: 120793
|
| |
|
|
|
|
| |
to avoid spurious errors due to previous fix.
llvm-svn: 120762
|
| |
|
|
|
|
| |
process or not.
llvm-svn: 120761
|
| |
|
|
|
|
|
|
|
|
| |
Add bool member to Communication class indicating whether the
Connection should be closed on receiving an EOF or not. Update the
Connection read to return an EOF status when appropriate. Modify the
Communication class to pass the EOF along or not, and to close the
Connection or not, as appropriate.
llvm-svn: 120723
|
| |
|
|
|
|
|
|
| |
control-c)
and end-of-file (often control-d).
llvm-svn: 119837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
changing it to use it. There was an extra parameter added to the static
accessor global user settings controllers that wasn't needed. A bool was being
used as a parameter to the accessor just so it could be used to clean up
the global user settings controller which is now fixed by splitting up the
initialization into the "static void Class::Initialize()", access into the
"static UserSettingsControllerSP & Class::GetSettingsController()", and
cleanup into "static void Class::Terminate()".
Also added initialize and terminate calls to the logging code to avoid issues
when LLDB is shutting down. There were cases after the logging was switched
over to use shared pointers where we could crash if the global destructor
chain was being run and it causes the log to be destroyed and any any logging
occurred.
llvm-svn: 119757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to the DoHalt down in ProcessGDBRemote. I also moved the functionality that
was in ProcessGDBRemote::DoHalt up into Process::Halt so not every class has
to implement a tricky halt/resume on the internal state thread. The
functionality is the same as it was before with two changes:
- when we eat the event we now just reuse the event we consume when the private
state thread is paused and set the interrupted bool on the event if needed
- we also properly update the Process::m_public_state with the state of the
event we consume.
Prior to this, if you issued a "process halt" it would eat the event, not
update the process state, and then produce a new event with the interrupted
bit set and send it. Anyone listening to the event would get the stopped event
with a process that whose state was set to "running".
Fixed debugserver to not have to be spawned with the architecture of the
inferior process. This worked fine for launching processes, but when attaching
to processes by name or pid without a file in lldb, it would fail.
Now debugserver can support multiple architectures for a native debug session
on the current host. This currently means i386 and x86_64 are supported in
the same binary and a x86_64 debugserver can attach to a i386 executable.
This change involved a lot of changes to make sure we dynamically detect the
correct registers for the inferior process.
llvm-svn: 119680
|
| |
|
|
|
|
| |
they have to get cleaned up in the derived class's destructor. Make sure that happens.
llvm-svn: 119675
|
| |
|
|
|
|
|
|
|
| |
with the Interrupted bit set. Process::HandlePrivateEvent ignores Interrupted events.
DoHalt is changed to ensure that the stop even is processed, and an event with
the Interrupted event is posted. Finally ClangFunction is rationalized to use this
facility so the that Halt is handled more deterministically.
llvm-svn: 119453
|
| |
|
|
|
|
|
|
|
| |
ReadThread stuff into the main Process class (out of the Process Plugins).
This has the (intended) side effect of disabling the command line tool
from reading input/commands while the process is running (the input is
directed to the running process rather than to the command interpreter).
llvm-svn: 119329
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a pseudo terminal even when the process being attached to.
Fixed a possible crasher in the in:
bool
ClangASTContext::IsAggregateType (clang_type_t clang_type);
It seems that if you pass in a record decl, enum decl, or objc class decl
and ask it if it is an aggregate type, clang will crash.
llvm-svn: 118404
|
| |
|
|
|
|
|
|
|
|
|
| |
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
|
| |
|
|
|
|
|
|
| |
pseudoterminal to pass to the inferior for the inferior's I/O
(to allow direct writing, rather than passing all the I/O around
via packets).
llvm-svn: 118308
|
| |
|
|
| |
llvm-svn: 118264
|
| |
|
|
|
|
|
| |
or the native unwinder (UnwindLLDB). I'll make the native unwinder the default
once I check in with everyone tomorrow.
llvm-svn: 118243
|
| |
|
|
|
|
| |
that in along with some cleanup work with the native unwinder code.
llvm-svn: 118242
|
| |
|
|
|
|
|
|
|
| |
fixed them. Added DISALLOW_COPY_AND_ASSIGN to classes that should
not be bitwise copied. Added default initializers for member
variables that weren't being initialized in the ctor. Fixed a few
shadowed local variable mistakes.
llvm-svn: 118240
|
| |
|
|
|
|
|
|
|
| |
than just the entire log channel.
Add checks, where appropriate, to make sure a log channel/category has
not been disabled before attempting to write to it.
llvm-svn: 117715
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all of the calls inlined in the header file for better performance.
Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.
Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.
llvm-svn: 117437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:
FileSpec::FileSpec (const char *path);
and in the:
void FileSpec::SetFile(const char *pathname, bool resolve = true);
This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:
(lldb) breakpoint set --file file.c --line 5
If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.
So I removed the constructor that just takes a path:
FileSpec::FileSpec (const char *path); // REMOVED
You must now use the other constructor that has a "bool resolve" parameter that you must always supply:
FileSpec::FileSpec (const char *path, bool resolve);
I also removed the default parameter to SetFile():
void FileSpec::SetFile(const char *pathname, bool resolve);
And fixed all of the code to use the right settings.
llvm-svn: 116944
|
| |
|
|
|
|
|
|
|
|
|
| |
but something is still killing our inferior.
Fixed an issue with darwin-debug where it wasn't passing all needed arguments
to the inferior.
Fixed a race condition with the attach to named process code.
llvm-svn: 116697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"vAttachName;<PROCNAME>" packet, and wait for a new process by name to launch
with the "vAttachWait;<PROCNAME>".
Fixed a few issues with attaching where if DoAttach() returned no error, yet
there was no valid process ID, we would deadlock waiting for an event that
would never happen.
Added a new "process launch" option "--tty" that will launch the process
in a new terminal if the Host layer supports the "Host::LaunchInNewTerminal(...)"
function. This currently works on MacOSX and will allow the debugging of
terminal applications that do complex operations with the terminal.
Cleaned up the output when the process resumes, stops and halts to be
consistent with the output format.
llvm-svn: 116693
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static bool
Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec);
This will fill in "file_spec" with an appropriate path that is appropriate
for the current Host OS. MacOSX will return paths within the LLDB.framework,
and other unixes will return the paths they want. The current PathType
enums are:
typedef enum PathType
{
ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists
ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc)
ePathTypeHeaderDir, // Find LLDB header file directory
ePathTypePythonDir // Find Python modules (PYTHONPATH) directory
} PathType;
All places that were finding executables are and python paths are now updated
to use this Host call.
Added another new host call to launch the inferior in a terminal. This ability
will be very host specific and doesn't need to be supported on all systems.
MacOSX currently will create a new .command file and tell Terminal.app to open
the .command file. It also uses the new "darwin-debug" app which is a small
app that uses posix to exec (no fork) and stop at the entry point of the
program. The GDB remote plug-in is almost able launch a process and attach to
it, it currently will spawn the process, but it won't attach to it just yet.
This will let LLDB not have to share the terminal with another process and a
new terminal window will pop up when you launch. This won't get hooked up
until we work out all of the kinks. The new Host function is:
static lldb::pid_t
Host::LaunchInNewTerminal (
const char **argv, // argv[0] is executable
const char **envp,
const ArchSpec *arch_spec,
bool stop_at_entry,
bool disable_aslr);
Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero
filling the entire path buffer.
Fixed an issue with the dynamic checker function where I missed a '$' prefix
that should have been added.
llvm-svn: 116690
|
| |
|
|
|
|
| |
shlib.
llvm-svn: 116315
|
| |
|
|
|
|
| |
obey the UnixSignals table that we have in the process.
llvm-svn: 116139
|
| |
|
|
|
|
| |
read or write all registers.
llvm-svn: 115992
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tricks to get types to resolve. I did this by correctly including the correct
files: stdint.h and all lldb-*.h files first before including the API files.
This allowed me to remove all of the hacks that were in the lldb.swig file
and it also allows all of the #defines in lldb-defines.h and enumerations
in lldb-enumerations.h to appear in the lldb.py module. This will make the
python script code a lot more readable.
Cleaned up the "process launch" command to not execute a "process continue"
command, it now just does what it should have with the internal API calls
instead of executing another command line command.
Made the lldb_private::Process set the state to launching and attaching if
WillLaunch/WillAttach return no error respectively.
llvm-svn: 115902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the start of Host specific launch services, though it currently isn't
hookup up to anything. We want to be able to launch a process and use the
native launch services to launch an app like it would be launched by the
user double clicking on the app. We also eventually want to be able to run
a command line app in a newly spawned terminal to avoid terminal sharing.
Fixed an issue with the new DWARF forward type declaration stuff. A crasher
was found that was happening when trying to properly expand the forward
declarations.
llvm-svn: 115213
|
| |
|
|
|
|
|
| |
Remove the GetUserData()/SetUserData() from the DWARFDebugInfoEntry
class. We now track everything with dense maps.
llvm-svn: 114876
|
| |
|
|
|
|
| |
to symbolicate things without the need for a valid process subclass.
llvm-svn: 113895
|
| |
|
|
|
|
| |
if sending of the packet fails for any reason.
llvm-svn: 113874
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).
The ObjectFile class now has an UnwindTable object.
The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.
The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.
UnwindPlans are created from different sources. One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw. Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.
Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs). Only a minimal set of registers is
recovered during a fast stack walk.
The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture). When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to
unwind. That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.
There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.
llvm-svn: 113581
|
