was done as an settings variable in the process for now. We will eventually
move all environment stuff over to the target, but we will leave it with the
process for now. The default setting is for a process to inherit the host
environment. This can be disabled by setting the "inherit-env" setting to
false in the process.
llvm-svn: 120862
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
comes from by using a virtual function to provide it from the Module's
SymbolVendor by default. This allows the DWARF parser, when being used to
parse DWARF in .o files with a parent DWARF + debug map parser, to get its
type list from the DWARF + debug map parser so when we go and find full
definitions for types (that might come from other .o files), we can use the
type list from the debug map parser. Otherwise we ended up mixing clang types
from one .o file (say a const pointer to a forward declaration "class A") with
the a full type from another .o file. This causes expression parsing, when
copying the clang types from those parsed by the DWARF parser into the
expression AST, to fail -- for good reason. Now all types are created in the
same list.
Also added host support for crash description strings that can be set before
doing a piece of work. On MacOSX, this ties in with CrashReporter support
that allows a string to be dispalyed when the app crashes and allows
LLDB.framework to print a description string in the crash log. Right now this
is hookup up the the CommandInterpreter::HandleCommand() where each command
notes that it is about to be executed, so if we crash while trying to do this
command, we should be able to see the command that caused LLDB to exit. For
all other platforms, this is a nop.
llvm-svn: 118672
the same architecture as a default program, the attach architecture auto
detection would change the architecture to the architecture of the darwin-debug
(which was always x86_64) and hose up your debug session.
llvm-svn: 118399
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
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
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
optionally specify the tty you want to use if you want to use an existing
terminal window by giving a partial or full path name:
(lldb) process launch --tty=ttys002
This would find the terminal window (or tab on MacOSX) that has ttys002 in its
tty path and use it. If it isn't found, it will use a new terminal window.
llvm-svn: 116878
We now spawn a thread to accept a unix socket connection from the inferior
when it spawns in the terminal, then we launch the process, then we get
the pid back through the unix socket, and then wait for it to SIGSTOP.
darwin-debug now clears the terminal screen and prints out the program and
arguments that are about to be launched.
llvm-svn: 116841
sockets so the driver doesn't just crash.
Added support for connecting to named sockets (unix IPC sockets) in
ConnectionFileDescriptor.
Modified the Host::LaunchInNewTerminal() for MacOSX to return the process
ID of the inferior process instead of the process ID of the Terminal.app. This
was done by modifying the "darwin-debug" executable to connect to lldb through
a named unix socket which is passed down as an argument. This allows a quick
handshake between "lldb" and "darwin-debug" so we can get the process ID
of the inferior and then attach by process ID and avoid attaching to the
inferior by process name since there could be more than one process with
that name. This still has possible race conditions, those will be fixed
in the near future. This fixes the SIGPIPE issues that were sometimes being
seen when task_for_pid was failing.
llvm-svn: 116792
"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
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
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
to spawn a thread for each process that is being monitored. Previously
LLDB would spawn a single thread that would wait for any child process which
isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on
linux). The old single thread used to call wait4() with a pid of -1 which
could cause it to reap child processes that it shouldn't have.
Re-wrote the way Function blocks are handles. Previously I attempted to keep
all blocks in a single memory allocation (in a std::vector). This made the
code somewhat efficient, but hard to work with. I got rid of the old BlockList
class, and went to a straight parent with children relationship. This new
approach will allow for partial parsing of the blocks within a function.
llvm-svn: 111706
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".
Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.
llvm-svn: 110624
ThreadCancel in Host::WillTerminate g_monitor_thread may be blocked on a call
to pthread_cond_wait (for example, line 640). Now, by default, when a
cancellation request is serviced g_monitor_thread will again own the mutex
guarding the condition variable it was waiting on. This causes the call to
SetValue in Host::WillTerminate to hit a deadlock.
The call to SetValue does not appear to be needed, so removing it solves
the issue.
Patch from Stephen Wilson.
llvm-svn: 109228
defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO
and ObjectContainerUniversalMachO to be able to be cross compiled in Linux.
Also did some cleanup on the ASTType by renaming it to ClangASTType and
renaming the header file. Moved a lot of "AST * + opaque clang type *"
functionality from lldb_private::Type over into ClangASTType.
llvm-svn: 109046
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.
llvm-svn: 108009
Greg Clayton