This is the error I got:
Debugger entered--Lisp error: (void-function split-string-and-unquote)
(split-string-and-unquote command-line)
(let* ((words ...) (program ...) (dir default-directory) (file-word ...) (file-subst ...) (args ...) (file ...) (filepart ...) (existing-buffer ...)) (pop-to$
gud-common-init("/Volumes/data/lldb/svn/trunk/build/Debug/lldb" nil gud-lldb-marker-filter)
lldb("/Volumes/data/lldb/svn/trunk/build/Debug/lldb")
call-interactively(lldb)
execute-extended-command(nil)
call-interactively(execute-extended-command)
The gud-common-init elisp function references split-string-and-unquote function
which is not defined there.
llvm-svn: 126449
Modifed lldb_private::Process to be able to handle connecting to a remote
target that isn't running a process. This leaves lldb_private::Process in the
eStateConnected state from which we can then do an attach or launch.
Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working
dir, disable ASLR and a few other settings down by using new GDB remote
packets. This allows us to keep all of our current launch flags and settings
intact and still be able to communicate them over to the remote GDB server.
Previously these were being sent as arguments to the debugserver binary that
we were spawning. Also modified ProcessGDBRemote to handle losing connection
to the remote GDB server and always exit immediately. We do this by watching
the lldb_private::Communication event bit for the read thread exiting in the
ProcessGDBRemote async thread.
Added support for many of the new 'Q' packets for setting stdin, stdout,
stderr, working dir and disable ASLR to the GDBRemoteCommunication class for
easy accesss.
Modified debugserver for all of the new 'Q' packets and also made it so that
debugserver always exists if it loses connection with the remote debugger.
llvm-svn: 126444
Also fix a bug where we were not lazily parsing the ELF header and thus
returning an ArchSpec with invalid cpu type components. Initialize the cpu
subtype as LLDB_INVALID_CPUTYPE for compatibility with the new ArchSpec
implementation.
llvm-svn: 126405
Previously we were using a set of preprocessor defines and returning an ArchSpec
without any OS/Vendor information. This fixes an issue with plugin resolution
on Linux where a valid OS component is needed.
llvm-svn: 126404
The major issue this patch solves is that ArchSpec::SetTriple no longer depends
on the implementation of Host::GetArchitecture. On linux, Host::GetArchitecture
calls ArchSpec::SetTriple, thus blowing the stack.
A second smaller point is that SetTriple now defaults to Host defined components
iff all OS, vendor and environment fields are not set.
llvm-svn: 126403
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
Add ARM/Thumb encoding entries for "CMN (immediate)" and "CMN (register)" operations,
with the EmulateCMNImm()/Reg() methods not implemented yet for now.
llvm-svn: 126178
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
which now handles R0-R12, SP, LR, as well as PC. And refactored a lot of
calls to ReadRegisterUnsigned() to now funnel through ReadCoreReg(), instead.
llvm-svn: 126010
Targets can now specify some additional parameters for when we debug
executables that can help with plug-in selection:
target.execution-level = auto | user | kernel
target.execution-mode = auto | dynamic | static
target.execution-os-type = auto | none | halted | live
On some systems, the binaries that are created are the same wether you use
them to debug a kernel, or a user space program. Many times inspecting an
object file can reveal what an executable should be. For these cases we can
now be a little more complete by specifying wether to detect all of these
things automatically (inspect the main executable file and select a plug-in
accordingly), or manually to force the selection of certain plug-ins.
To do this we now allow the specficifation of wether one is debugging a user
space program (target.execution-level = user) or a kernel program
(target.execution-level = kernel).
We can also specify if we want to debug a program where shared libraries
are dynamically loaded using a DynamicLoader plug-in
(target.execution-mode = dynamic), or wether we will treat all symbol files
as already linked at the correct address (target.execution-mode = static).
We can also specify if the inferior we are debugging is being debugged on
a bare board (target.execution-os-type = none), or debugging an OS where
we have a JTAG or other direct connection to the inferior stops the entire
OS (target.execution-os-type = halted), or if we are debugging a program on
something that has live debug services (target.execution-os-type = live).
For the "target.execution-os-type = halted" mode, we will need to create
ProcessHelper plug-ins that allow us to extract the process/thread and other
OS information by reading/writing memory.
This should allow LLDB to be used for a wide variety of debugging tasks and
handle them all correctly.
llvm-svn: 125815
Johnny Chen