(lldb) process connect <remote-url>
Currently when you specify a file with the file command it helps us to find
a process plug-in that is suitable for debugging. If you specify a file you
can rely upon this to find the correct debugger plug-in:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) process connect connect://localhost:2345
...
If you don't specify a file, you will need to specify the plug-in name that
you wish to use:
% lldb
(lldb) process connect --plugin process.gdb-remote connect://localhost:2345
Other connection URL examples:
(lldb) process connect connect://localhost:2345
(lldb) process connect tcp://127.0.0.1
(lldb) process connect file:///dev/ttyS1
We are currently treating the "connect://host:port" as a way to do raw socket
connections. If there is a URL for this already, please let me know and we
will adopt it.
So now you can connect to a remote debug server with the ProcessGDBRemote
plug-in. After connection, it will ask for the pid info using the "qC" packet
and if it responds with a valid process ID, it will be equivalent to attaching.
If it response with an error or invalid process ID, the LLDB process will be
in a new state: eStateConnected. This allows us to then download a program or
specify the program to run (using the 'A' packet), or specify a process to
attach to (using the "vAttach" packets), or query info about the processes
that might be available.
llvm-svn: 124846
condition that could occur when launching or attaching. What could happen is
you would launch/attach to a process, then you would need to tell a listener
to watch for process state changed events. In this case, if you waited too
long to listen for events, you could miss the initial stop event, requiring
clients to listen, then check the process state.
llvm-svn: 124818
substitutions in order to achieve file mappings.
Modify CommandObjectTarget.cpp to properly set the status of the return object to make
scripting like this:
self.runCmd("target image-search-paths add %s %s" % (os.getcwd(), new_dir))
works.
llvm-svn: 124762
LLDB plugin directory and a user LLDB plugin directory. We currently still
need to work out at what layer the plug-ins will be, but at least we are
prepared for plug-ins. Plug-ins will attempt to be loaded from the
"/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Plugins"
folder, and from the "~/Library/Application Support/LLDB/Plugins" folder on
MacOSX. Each plugin will be scanned for:
extern "C" bool LLDBPluginInitialize(void);
extern "C" void LLDBPluginTerminate(void);
If at least LLDBPluginInitialize is found, the plug-in will be loaded. The
LLDBPluginInitialize function returns a bool that indicates if the plug-in
should stay loaded or not (plug-ins might check the current OS, current
hardware, or anything else and determine they don't want to run on the current
host). The plug-in is uniqued by path and added to a static loaded plug-in
map. The plug-in scanning happens during "lldb_private::Initialize()" which
calls to the PluginManager::Initialize() function. Likewise with termination
lldb_private::Terminate() calls PluginManager::Terminate(). The paths for the
plug-in directories is fetched through new Host calls:
bool Host::GetLLDBPath (ePathTypeLLDBSystemPlugins, dir_spec);
bool Host::GetLLDBPath (ePathTypeLLDBUserPlugins, dir_spec);
This way linux and other systems can define their own appropriate locations
for plug-ins to be loaded.
To allow dynamic shared library loading, the Host layer has also been modified
to include shared library open, close and get symbol:
static void *
Host::DynamicLibraryOpen (const FileSpec &file_spec,
Error &error);
static Error
Host::DynamicLibraryClose (void *dynamic_library_handle);
static void *
Host::DynamicLibraryGetSymbol (void *dynamic_library_handle,
const char *symbol_name,
Error &error);
lldb_private::FileSpec also has been modified to support directory enumeration
in an attempt to abstract the directory enumeration into one spot in the code.
The directory enumertion function is static and takes a callback:
typedef enum EnumerateDirectoryResult
{
eEnumerateDirectoryResultNext, // Enumerate next entry in the current directory
eEnumerateDirectoryResultEnter, // Recurse into the current entry if it is a directory or symlink, or next if not
eEnumerateDirectoryResultExit, // Exit from the current directory at the current level.
eEnumerateDirectoryResultQuit // Stop directory enumerations at any level
};
typedef FileSpec::EnumerateDirectoryResult (*EnumerateDirectoryCallbackType) (void *baton,
FileSpec::FileType file_type,
const FileSpec &spec);
static FileSpec::EnumerateDirectoryResult
FileSpec::EnumerateDirectory (const char *dir_path,
bool find_directories,
bool find_files,
bool find_other,
EnumerateDirectoryCallbackType callback,
void *callback_baton);
This allow clients to specify the directory to search, and specifies if only
files, directories or other (pipe, symlink, fifo, etc) files will cause the
callback to be called. The callback also gets to return with the action that
should be performed after this directory entry. eEnumerateDirectoryResultNext
specifies to continue enumerating through a directory with the next entry.
eEnumerateDirectoryResultEnter specifies to recurse down into a directory
entry, or if the file is not a directory or symlink/alias to a directory, then
just iterate to the next entry. eEnumerateDirectoryResultExit specifies to
exit the current directory and skip any entries that might be remaining, yet
continue enumerating to the next entry in the parent directory. And finally
eEnumerateDirectoryResultQuit means to abort all directory enumerations at
all levels.
Modified the Declaration class to not include column information currently
since we don't have any compilers that currently support column based
declaration information. Columns support can be re-enabled with the
additions of a #define.
Added the ability to find an EmulateInstruction plug-in given a target triple
and optional plug-in name in the plug-in manager.
Fixed a few cases where opendir/readdir was being used, but yet not closedir
was being used. Soon these will be deprecated in favor of the new directory
enumeration call that was added to the FileSpec class.
llvm-svn: 124716
diagnostics of Clang AST classes for the purpose of
debugging the types LLDB produces for DWARF objects.
The ASTDumper is currently only used in log output
if you enable verbose mode in the expression log:
log enable -v lldb expr
Its output then appears in the log for external
variables used by the expr command.
llvm-svn: 124703
sessions: When continue packet has been sent and an interrupt packet was
quickly sent, it would get read at the same time:
$c#00\x03
There was an error where the packet end index was always being computed
incorrectly by debugserver, but it wouldn't matter if there weren't extra
bytes on the end (the hex \x03 interrupt byte in this case). The first
'$' last 3 bytes of the data in the packet buffer were being trimmed
(trying to trim the '#' + checksum (#XX)) which made:
c#
And this would then be passed to the handle routine for the 'c' packet which
would see an extra character at the end and assume it was going to be in the
form c[addr] where "[addr]" was a hex address to resume at and this would
result in a malformed packet response. This is now fixed and everything works
great.
Another issue was issuing async packets correctly by doing correct handshakes
between the thread that wants to send the async packet, and the thread that
is tracking the current run.
Added a write lock to the communication class as well to make sure you never
get two threads trying to write data at the same time. This wasn't happening,
but it is a good idea to make sure it doesn't.
llvm-svn: 124369
lldb_private::Function objects. Previously the SymbolFileSymtab subclass
would return lldb_private::Symbol objects when it was asked to find functions.
The Module::FindFunctions (...) now take a boolean "bool include_symbols" so
that the module can track down functions and symbols, yet functions are found
by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are
gotten through the ObjectFile plug-ins.
Fixed and issue where the DWARF parser might run into incomplete class member
function defintions which would make clang mad when we tried to make certain
member functions with invalid number of parameters (such as an operator=
operator that had no parameters). Now we just avoid and don't complete these
incomplete functions.
llvm-svn: 124359
Greg Clayton