We were dropping the expansion of -rpath=$(LibDir) on linux, which resulted in
the build not being able to resolve libLLVM.so. Bring in the definition before
expanding the values hanging off LD.Flags.
Thanks to Jason E. Aten for reporting this!
llvm-svn: 127570
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.
So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx
This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>
The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.
llvm-svn: 127286
N streams by making the stream a vector of stream shared pointers
that is protected by a mutex. Streams can be get/set by index which
allows indexes to be defined as stream indentifiers. If a stream is
set at index 3 and there are now streams in the collection, then
empty stream objects are inserted to ensure that stream at index 3
has a valid stream. There is also an append method that allows a stream
to be pushed onto the stack. This will allow our streams to be very
flexible in where the output goes.
Modified the CommandReturnObject to use the new StreamTee functionality.
This class now defines two StreamTee indexes: 0 for the stream string
stream, and 1 for the immediate stream. This is used both on the output
and error streams.
Added the ability to get argument types as strings or as descriptions.
This is exported through the SBCommandInterpreter API to allow external
access.
Modified the Driver class to use the newly exported argument names from
SBCommandInterpreter::GetArgumentTypeAsCString().
llvm-svn: 126067
a Stream, and then added GetOutputData & GetErrorData to get the accumulated data.
- Added a StreamTee that will tee output to two provided lldb::StreamSP's.
- Made the CommandObjectReturn use this so you can Tee the results immediately to
the debuggers output file, as well as saving up the results to return when the command
is done executing.
- HandleCommands now uses this so that if you have a set of commands that continue the target
you will see the commands come out as they are processed.
- The Driver now uses this to output the command results as you go, which makes the interface
more reactive seeming.
llvm-svn: 126015
(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
used as the arguments for the inferior program. So for example you can do
% lldb /bin/ls /tmp ~/Documents
And "lldb" will use "/bin/ls" as the program and send arguments "/tmp" and
"~/Documents" as the launch args.
If you specify a file, then all remaining args after option parsing
will be used for program arguments:
% lldb -f /bin/ls /tmp ~/Documents
If you need to pass option values to your inferior program, just terminate
the "lldb" command line driver options with "--":
% lldb -- /bin/ls -AFl /tmp
The arguments are placed into the "settings" variable named
"target.process.run-args". This allows you to just run the program using
"process launch" and, if no args are specified on that command, the
"target.process.run-args" values will be used:
% lldb -- /bin/ls -AFl /tmp
Current executable set to '/bin/ls' (x86_64).
(lldb) settings show target.process.run-args
target.process.run-args (array):
[0]: '-AFl'
[1]: '/tmp'
(lldb)
(lldb) r
Process 56753 launched: '/bin/ls' (x86_64)
lrwxr-xr-x@ 1 root wheel 11 Nov 19 2009 /tmp@ -> private/tmp
llvm-svn: 121295
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
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
where the DWARF is in the .o files so they can track down the actual type for
a forward declaration. This was working before for just DWARF files, but not
for DWARF in .o files where the actual definition was in another .o file.
Modified the main thread name in the driver to be more consistent with the
other LLDB thread names.
llvm-svn: 118383
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
arguments are specified in a standardized way, will have a standardized name, and
have functioning help.
The next step is to start writing useful help for all the argument types.
llvm-svn: 115335
accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.
While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.
Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").
llvm-svn: 114252
handles user settable internal variables (the equivalent of set/show
variables in gdb). In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes). The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure. The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter. Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)
Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class). The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).
llvm-svn: 113041
o Fixed a crasher when getting it via SBTarget.GetExecutable().
>>> filespec = target.GetExecutable()
Segmentation fault
o And renamed SBFileSpec::GetFileName() to GetFilename() to be consistent with FileSpec::GetFilename().
llvm-svn: 112308
Makefile patch to explicitly use PROJ_SRC_DIR when required. It fixes
build when obj dir is not source dir.
I also fixed a build warning in ClangResultSynthesizer.cpp.
llvm-svn: 108210
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
intelligently. The four name types we currently have are:
eFunctionNameTypeFull = (1 << 1), // The function name.
// For C this is the same as just the name of the function
// For C++ this is the demangled version of the mangled name.
// For ObjC this is the full function signature with the + or
// - and the square brackets and the class and selector
eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class
// methods or selectors will be searched.
eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments
eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names
this allows much more flexibility when setting breakoints:
(lldb) breakpoint set --name main --basename
(lldb) breakpoint set --name main --fullname
(lldb) breakpoint set --name main --method
(lldb) breakpoint set --name main --selector
The default:
(lldb) breakpoint set --name main
will inspect the name "main" and look for any parens, or if the name starts
with "-[" or "+[" and if any are found then a full name search will happen.
Else a basename search will be the default.
Fixed some command option structures so not all options are required when they
shouldn't be.
Cleaned up the breakpoint output summary.
Made the "image lookup --address <addr>" output much more verbose so it shows
all the important symbol context results. Added a GetDescription method to
many of the SymbolContext objects for the more verbose output.
llvm-svn: 107075
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create());
// Use which ever file handles you wish
debugger.SetErrorFileHandle (stderr, false);
debugger.SetOutputFileHandle (stdout, false);
debugger.SetInputFileHandle (stdin, true);
// main loop
SBDebugger::Terminate(); // (static function)
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.
Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.
llvm-svn: 106615
Fixed the Disassemble arguments so you can't specify start address or name in multiple ways.
Fixed the command line input so you can specify the filename without "-f" even if you use other options.
llvm-svn: 106020
The top of the header file seems to indicate that this was
intended to be over at include/lldb/Core but we should be in line
with the .cpp file's location so it's include/lldb/Utility for now.
llvm-svn: 105753
Stephen Wilson