bool SBDebugger::DeleteTarget(lldb::SBTarget &target);
which is used in the test tearDown() phase to cleanup the debugger's target list
so that it won't grow larger and larger as test cases are executed. This is also
a good opportunity to get rid of the arcane requirement that test cases exercising
the Python API must assign the process object to self.process so that it gets
shutdown gracefully. Instead, the shutdown of the process associated with each
target is now being now automatically.
Also get rid of an API from SBTarget class:
SBTarget::DeleteTargetFromList(lldb_private::TargetList *list);
llvm-svn: 133091
like the doc's say it should. Make sure we have a condition before we set up a test whether
we have one, so we only present a "could not parse condition" error if we actually have a condition.
llvm-svn: 133088
embedded_interpreter.py file rather than keeping it
all in a string and compiling the string (easier to maintain,
easier to read, remove redundancy).
llvm-svn: 132935
to have the value for the map be a "const char *" instead of an unused uint32_t.
This allows us to store the uniqued mangled/demangled counterpart in this map
for mangled names. This also speeds up the mangled/demangled counterpart lookup
that used to be maintained in a STL map by having direct access to the data.
If we eventually need to associate other strings to strings to more data, we
can make the value of the StringMap have a more complex value.
Added the start of a history source and history event class. It isn't being
used by anything yet, but might be shortly.
llvm-svn: 132813
- The Swig post-processing scripts are now run.
- edit-swig-python-wrapper-file.py has been modified so it can be run
from the Makefile.
- The issue that prompted me to pass -classic to swig is fixed by this,
so -classic isn't passed anymore.
Python shouldn't complain anymore about a missing method 'FindDebuggerByID'
on the SBDebugger object whenever lldb is run.
llvm-svn: 132383
they don't update correctly. Currently if a variable is unavailable due to
a register not being available in a higher frame or due to the PC value
not being a valid location list value, "<unknown type>" will get displayed
as the variable type. I am not sure what other things will fail, so I am
disabling it for now just by letting the default enumeration value default
to it being disabled.
llvm-svn: 132303
(or anything running in a terminal) wants. Not what a UI (Xcode) would want
where it creates a debugger per debug window. The current code had an infinite
loop after a debug session ended.
llvm-svn: 132280
virtual bool
ABI::StackUsesFrames () = 0;
Should return true if your ABI uses frames when doing stack backtraces. This
means a frame pointer is used that points to the previous stack frame in some
way or another.
virtual bool
ABI::CallFrameAddressIsValid (lldb::addr_t cfa) = 0;
Should take a look at a call frame address (CFA) which is just the stack
pointer value upon entry to a function. ABIs usually impose alignment
restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed.
This function should return true if "cfa" is valid call frame address for
the ABI, and false otherwise. This is used by the generic stack frame unwinding
code to help determine when a stack ends.
virtual bool
ABI::CodeAddressIsValid (lldb::addr_t pc) = 0;
Validates a possible PC value and returns true if an opcode can be at "pc".
Some ABIs or architectures have fixed width instructions and must be aligned
to a 2 or 4 byte boundary. "pc" can be an opcode or a callable address which
means the load address might be decorated with extra bits (such as bit zero
to indicate a thumb function call for ARM targets), so take this into account
when returning true or false. The address should also be validated to ensure
it is a valid address for the address size of the inferior process. 32 bit
targets should make sure the address is less than UINT32_MAX.
Modified UnwindLLDB to use the new ABI functions to help it properly terminate
stacks.
Modified the mach-o function that extracts dependent files to not resolve the
path as the paths inside a binary might not match those on the current
host system.
llvm-svn: 132021