The right thing to do here would be to give the ASTConsumer to the
CompilerInstance so it can set things up for us, but we can't do that
because we don't own it. So instead just initialize it ourselves.
llvm-svn: 245397
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
We don't need to do the fancy dance with checking whether the iterator
represents a #define -- in fact, that's the wrong thing to do. The thing to do
is check whether the highest-priority module that did something to the module
#defined or #undefd it. If it #defined it, then the MacroInfo* will be non-NULL
and we're good to go.
llvm-svn: 241651
Recently lldb_private::Symbol was changed so the old code:
Address &Symbol::GetAddress();
Is now:
Address Symbol::GetAddress();
And the Address object that is returned will be invalid for non-address based symbols. When we have re-exported symbols this code would now fail:
const Address sym_address = sym_ctx.symbol->GetAddress();
if (!sym_address.IsValid())
continue;
symbol_load_addr = sym_ctx.symbol->ResolveCallableAddress(*target_sp);
if (symbol_load_addr == LLDB_INVALID_ADDRESS)
{
symbol_load_addr = sym_address.GetLoadAddress(target_sp.get());
}
It used to return an Address reference to the value of the re-exported symbol that contained no section and a zero value for Address.m_offset (since the original symbol in the symbol table had a value of zero). When a reference was returned, this meant the "sym_address.IsValid()" would return true because the Address.m_offset was not LLDB_INVALID_ADDRESS, it was zero. This was working by mistake.
The Symbol::ResolveCallableAddress(...) actually checks for reexported symbols and whole bunch of other cases and resolves the address correctly, so we should let it do its thing and not cut it off before it can resolve the address with the "if (!sym_address.IsValid()) continue;".
llvm-svn: 241282
The new names clarify that the members have to do with the execution
context and not the language. For example, m_cplusplus was renamed to
m_in_cplusplus_method.
llvm-svn: 241132
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
it an extern "C" function instead of a C++ function
so that Clang doesn't emit a mangled function reference.
Also removed the hack in ClangExpressionDeclMap that
works around this.
llvm-svn: 238476
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
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
(including inline functions) from modules in the
expression parser. We now have to retain a reference
to the code generator in ClangExpressionDeclMap so
that any imported function bodies can be appropriately
sent to that code generator.
<rdar://problem/19883002>
llvm-svn: 236297
global convenience expression prefix. Also ensured
that if macros are defined by the modules we don't
try to redefine them. Finally cleaned up a bit of
code while I was in there.
<rdar://problem/20756642>
llvm-svn: 236266
module-loading support for the expression parser.
- It adds support for auto-loading modules referred
to by a compile unit. These references are
currently in the form of empty translation units.
This functionality is gated by the setting
target.auto-import-clang-modules (boolean) = false
- It improves and corrects support for loading
macros from modules, currently by textually
pasting all #defines into the user's expression.
The improvements center around including only those
modules that are relevant to the current context -
hand-loaded modules and the modules that are imported
from the current compile unit.
- It adds an "opt-in" mechanism for all of this
functionality. Modules have to be explicitly
imported (via @import) or auto-loaded (by enabling
the above setting) to enable any of this
functionality.
It also adds support to the compile unit and symbol
file code to deal with empty translation units that
indicate module imports, and plumbs this through to
the CompileUnit interface.
Finally, it makes the following changes to the test
suite:
- It adds a testcase that verifies that modules are
automatically loaded when the appropriate setting
is enabled (lang/objc/modules-auto-import); and
- It modifies lanb/objc/modules-incomplete to test
the case where a module #undefs something that is
#defined in another module.
<rdar://problem/20299554>
llvm-svn: 235313
all the macros from the modules the user has loaded.
These macros are currently imported textually into
the expression's source code, which turns out not to
impose the horrific string processing overhead that
I thought it would, but I still plan to look into
performance improvements.
Also modified TestCModules to test that this works.
llvm-svn: 234922
relocations. We used to do GEP on a pointer to
the result type, which is wrong. We should be doing
GEP on a pointer to char, which allows us to offset
correctly.
This fixes the C modules testcase, so it's no longer
ExpectFail.
llvm-svn: 234918
Summary:
This fixes an issue with GCC generated binaries wherein an expression
with method invocations on std::string variables was failing. Such use
cases are tested in TestSTL (albeit, in a test marked with
@unittest2.expectedFailure because of other reasons).
The reason for this particular failure with GCC is that the generated
DWARF for std::basic_string<...> is incomplete, which makes clang not
to use the alternate mangling scheme. GCC correctly generates the name
of basic_string<...>:
DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >"
It also lists the template parameters of basic_string correctly:
DW_TAG_template_type_parameter
DW_AT_name "_CharT"
DW_AT_type <0x0000009c>
DW_TAG_template_type_parameter
DW_AT_name "_Traits"
DW_AT_type <0x00000609>
DW_TAG_template_type_parameter
DW_AT_name "_Alloc"
DW_AT_type <0x000007fb>
However, it does not list the template parameters of std::char_traits<>.
This makes Clang feel (while parsing the expression) that the string
variable is not actually a basic_string instance, and consequently does
not use the alternate mangling scheme.
Test Plan:
dotest.py -C gcc -p TestSTL
-- See it go past the "for" loop expression successfully.
Reviewers: clayborg, spyffe
Reviewed By: clayborg, spyffe
Subscribers: tberghammer, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8846
llvm-svn: 234522
Summary:
If a struct type S has a member T that has a member that is a function that
returns a typedef of S* the respective field would be duplicated, which caused
an assert down the line in RecordLayoutBuilder. This patch adds a check that
removes the possibility of trying to resolve the same type twice within the
same callstack.
This commit also adds unit tests for these failures.
Fixes https://llvm.org/bugs/show_bug.cgi?id=20486.
Patch by Cristian Hancila.
Test Plan: Run unit tests.
Reviewers: clayborg spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8561
llvm-svn: 234441
in a session would be silently ignored by the compiler
because the compiler looked at its SourceLocation and
decided it had already handled it.
Also updated the relevant test case.
<rdar://problem/20315447>
llvm-svn: 234330
This used to be the case for "printf" before a function prototype was added to the builtin expression prefix file. This fix makes sure that if we get a mangled name that we don't find in the current target, that we only fall back to looking up function by basename if the function isn't contained in a namespace or class (no decl context).
llvm-svn: 234178
verifying that the types from that module don't
override types from DWARF. Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.
<rdar://problem/18805055>
llvm-svn: 234016
A char can have signed and unsigned encoding but previously lldb always
assumed it is signed. This CL adds a logic to detect the encoding of
'char' types based on the default encoding on the target architecture.
It fixes variable printing and expression evaluation on architectures
where 'char' is signed by default.
Differential revision: http://reviews.llvm.org/D8636
llvm-svn: 233682
Since ClangASTSource::layoutRecordType() was overriding a virtual
function in the base, this was inadvertently causing a new method
to be introduced rather than an override. To fix this all method
signatures are changed back to taking DenseMaps, and the `override`
keyword is added to make sure this type of error doesn't happen
again.
To keep the original fix intact, which is that fields and bases
must be added in offset order, the ImportOffsetMap() function
now copies the DenseMap into a vector and then sorts the vector
on the value type (e.g. the offset) before iterating over the
sorted vector and inserting the items.
llvm-svn: 233099
Prior to this patch, we would try to synthesize class types by
iterating over a DenseMap of FieldDecls and adding each one to
a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic
ordering of the elements, this would not add the fields in
FieldOffset order, but rather in some random order determined by
the memory layout of the DenseMap.
This patch fixes the issue by changing DenseMaps to vectors. The
ability to lookup a value in the DenseMap was hardly being used,
and where it is sufficient to do a vector lookup.
Differential Revision: http://reviews.llvm.org/D8512
llvm-svn: 233090
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
The issue can happen if you strip your main executable and then run an expression and it would fail to find the stripped symbol and it would then not be able to make the function call. The issue was fixed by doing our normal FindFunctions call.
<rdar://problem/20072750>
llvm-svn: 231667
Paul Herman