This patch fixes a bunch of issues that show up on big-endian systems:
- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
bit vectors: it should identify the enclosing *word* and then access
the appropriate bit within that word. Instead, the script simply
operates on bytes. This gives the same result on little-endian
systems, but not on big-endian.
- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
is UTF16, even though it could also be UTF8 or UTF32. This is mostly
not an issue on little-endian systems, but immediately fails on BE.
Fixed by checking the size of wchar_t like WCharStringSummaryProvider
already does.
- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
the virtual base offset stored in the vtable, even though the size
of this field matches the target pointer size according to the C++
ABI. Again, this is mostly not visible on LE, but fails on BE.
- Process::ReadStringFromMemory uses strncmp to search for a terminator
consisting of multiple zero bytes. This doesn't work since strncmp
will stop already at the first zero byte. Use memcmp instead.
Differential Revision: http://reviews.llvm.org/D18983
llvm-svn: 266313
Old-style syntax: `except Exception, e:`
New-style syntax: `except Exception as e:`
These two statements are identical, except that the former has
been deprecated for may versions, and was removed in Python 3.
This converts everything to use the new syntax (which also works
in Python 2). I had to convert unittest2 as well. What we really
need to do is just delete unittest2, and use unittest instead since
it is a standard module that ships with every Python distribution.
But this is the path of least resistance for now, although at
some point we will really need to do it.
llvm-svn: 251968
Even though these are under examples/, they actually get loaded
when LLDB starts up during initialization of ScriptInterpreterPython.
There's obviously some kind of layering issue here (and comments
in the code even point to that as well), but for now just make them
py3 compatible.
llvm-svn: 250710
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
version of this script. We picked up a bug at some point in March
where scripts that fail to call SBDebugger::Destroy() will crash
in the Debugger C++ dtor. I want to track the change down which
introduced the change - but this script should be calling
SBDebugger::Destroy() in the first place, so do that.
llvm-svn: 233779
The previous implementation only read out the first element of the
underlying storage array. Because of it only the first 32 (on x86) or
the first 64 (on x86_64) element was displayed.
Differential revision: http://reviews.llvm.org/D8585
llvm-svn: 233179
Summary:
GCC does not emit some DWARF required for the simplified formatter
to work. A workaround for it has been incorporated in the formatter.
The corresponding test TestDataFormatterStdMap has also been enabled
for GCC.
Test Plan: dotest.py -C <clang|gcc> -p TestDataFormatterStdMap
Reviewers: clayborg, vharron, granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8424
llvm-svn: 232678
Summary:
The existing formatter in C++ has been removed as it was not being used.
The associated test TestDataFormatterStdVBool.py has been enabled for
both Clang and GCC on Linux.
Test Plan: dotest.py -p TestDataFormatterStdVBool
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8390
llvm-svn: 232548
- tree items can define any number of key/value pairs
- creating a tree you specify which columns you want to display and it will pick out the right key/value pairs from the new tree item dictionaries
- added new "tk-target" command to explore the target's images, sections, symbols, compile units and line tables.
llvm-svn: 219219
If you "command script import" this file, then you will have two new commands:
(lldb) tk-variables
(lldb) tk-process
Not sure how this will work on all other systems, but on MacOSX, you will get a window with a tree view that allows you to inspect your local variables by expanding variables to see the child values.
The "tk-process" allows you to inspect the currently selected process by expanding the process to see the threads, the threads to see the frames, and the frames to see the variables. Very handy if you want to view variables for all frames simultaneously.
llvm-svn: 218279
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
- If there is only 1 frame ptr_refs now works (fixed issue with stack detection)
- Fixed test for result now that it isn't a pointer anymore
llvm-svn: 198712
This commit adds an example python file that can be used with 'target-definition-file' setting for Linux gdbserver.
This file has an extra key 'breakpoint-pc-offset' that LLDB uses to determine how much to change the PC
after hitting the breakpoint.
llvm-svn: 192962
- Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication
- Finished up the target definition python setting stuff.
- Added a new "slice" key/value pair that can specify that a register is part of another register:
{ 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' },
- Added a new "composite" key/value pair that can specify that a register is made up of two or more registers:
{ 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] },
- Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers:
{ 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']},
This now completes the feature that allows a GDB remote target to completely describe itself.
llvm-svn: 192858
Jim Ingham