platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)
When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can
do:
(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib
Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.
This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.
llvm-svn: 127934
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:
uint32_t
ArchSpec::GetMachOCPUType () const;
uint32_t
ArchSpec::GetMachOCPUSubType () const;
But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.
All code has been updated to deal with the changes.
This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.
llvm-svn: 126278
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
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
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
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
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