o int_to_bytearray()
o bytearray_to_int()
They return/interpret the bytearray in the little endian format.
For big endian, simply perform ba.reverse() on the bytearray object.
And modify TestProcessAPI.py to take advantage of the functions.
llvm-svn: 126813
among other SBProcess APIs, to write (int)256 into a memory location of a global variable
(int)my_int and reads/checks the variable afterwards.
llvm-svn: 126792
the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.
On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.
llvm-svn: 126736
otherwise, use the thing the debugserver is started with.
Fixed rdar://problem/9056462
The process launch flag '-w' for setting the current working directory not working?
llvm-svn: 126537
current working directory when running the inferior. Radar filed:
# rdar://problem/9056462
# The process launch flag '-w' for setting the current working directory not working?
llvm-svn: 126529
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
Johnny Chen