| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
stdout_path, and stderr_path
is just wrong and resulted in the inferior's output getting mixed into the GDB remote communication's
log file. Change all test cases to not pass os.ctermid() and either use SBTarget.LaunchSimple() or
SBTarget.Launch() and pass None as stdin_path/stdout_path/srderr_path to use a pseudo terminal.
rdar://problem/9716499 program output is getting mixed into the GDB remote communications
llvm-svn: 134940
|
|
|
|
|
|
|
|
| |
the frame argument.
Only the val (of SBValue type) argument is needed.
llvm-svn: 134915
|
|
|
|
|
|
|
|
|
| |
to self.process
in order to have its process cleaned up (terminated) upon tearDown is gone for good.
Let's simplify a bunch of Python API test cases.
llvm-svn: 133097
|
|
|
|
|
|
|
| |
those lldb objects which implement the IsValid() method, let's change the rest of
the test suite to use the more compact truth value testing pattern (the Python way).
llvm-svn: 131970
|
|
|
|
|
|
|
|
| |
be consistent.
And modify the test cases accordingly.
llvm-svn: 130314
|
|
|
|
| |
llvm-svn: 129792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for "frame var" and for the
expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.
The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.
There's also a general setting:
target.prefer-dynamic-value (boolean) = 'true'
which is consulted if you call "frame var" without supplying a value for the -d option.
llvm-svn: 129623
|
|
|
|
|
|
|
|
|
|
|
| |
SBProcess.RemoteLaunch()
API with a process not in eStateConnected, and checks that the remote launch failed.
Modify SBProcess::RemoteLaunch()/RemoteAttachToProcessWithID()'s log statements to fix a
crasher when logging is turned on.
llvm-svn: 127055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
// When stopped on breakppint 1, and then 2, we can get the line entries using
// SBFrame API SBFrame.GetLineEntry(). We'll get the start addresses for the
// two line entries; with the start address (of SBAddress type), we can then
// resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress().
//
// The two symbol context should point to the same symbol, i.e., 'a' function.
Add two utility functions to lldbutil.py:
o get_stopped_threads(process, reason):
return the list of threads with the specified stop reason or an empty list if not found
o get_stopped_thread(process, reason):
return the first thread with the given stop reason or None if not found
llvm-svn: 126916
|
|
|
|
| |
llvm-svn: 126867
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
GetByteOrder(),
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
|
|
|
|
| |
llvm-svn: 126774
|
|
|
|
|
|
| |
This makes the number of total tests equal to 201.
llvm-svn: 126769
|
|
particular, this tests
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
|