In http://reviews.llvm.org/D9754 I enabled the mangled symbol name lookup
workaround used to find global and anonymous namespace symbols in linux binaries
for all platforms, however we should still only check for these symbols when
processing Linux or FreeBSD binaries where they are relevant. This patch makes
this change.
Test Plan: The tests from the original revision still pass:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9782
llvm-svn: 237467
all hosts.
We require a workaround to be able to locate global and anonymous namespace
functions in the dwarf symbols on linux binaries. This patch enables this code
on all platforms so that we can still find these symbols when debugging from a
different host platform.
Test Plan:
The following tests begin passing when running with a mac host to linux client:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9754
llvm-svn: 237270
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
Summary:
This is similar to the change introduced for variable DIEs in r233098. If the
linkage names of functions are missing in the DWARF, then their fully qualified
names (similar to the name that would be got by demangling their linkage name)
is generated using the decl context.
This change fixes TestNamespace when the test case is compiled with GCC, hence
it is enabled for GCC. The test and the test case are also enhanced to cover
variadic functions.
Test Plan: dotest.py -C <clang|gcc> -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8623
llvm-svn: 233336
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
Summary:
This commit adds this alternate route only when parsing variable dies
corresponding to global or static variables. The motivation for this is that GCC
does not emit linkage names for functions and variables declared/defined in
anonymous namespaces. Having this alternate route fixes one part of
TestNamespace which fails when the test case is compiled with GCC.
An alternate route to get fully qualified names of functions whose linkage names
are missing will be added with a followup change. With that, the other failing
part of TestNamespace will also be fixed.
Test Plan: dotest.py -C gcc -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8569
llvm-svn: 233098
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
Summary:
SymbolFileDWARF was not respecting the include_inlines argument in function lookup in all code
paths. This resulted in an attempt to call an inlined function during expression evaluation,
which is impossible, and usually resulted in a segfault in the inferior. This patch makes sure
include_inlines is respected in all code paths.
Reviewers: clayborg
Subscribers: lldb-commits, sivachandra
Differential Revision: http://reviews.llvm.org/D8286
llvm-svn: 232151
Now we make sure to update our DWARFCompileUnit -> lldb_private::CompileUnit user data when it isn't set to ensure quick transitions between the two.
<rdar://problem/18371367>
llvm-svn: 228264
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
Summary:
GCC emits DW_TAG_subrange_type for static member arrays, but with no
attributes. This in turn results in wrong type/value of the array when
printing with 'target variable <array var name>'. This patch fixes this
so that the array value is printed in this format:
(<element type> []) <array var name> = {}
Earlier, the array was being interpreted to be of its element type.
Note: This does not fix anything to do with 'expr' or 'p' commands.
Those commands still error out complaining about incomplete types.
Test Plan: dotest.py -p TestStaticVariables
Reviewers: emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6799
llvm-svn: 225219
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDIE (
DWARFCompileUnit* dwarf_cu,
const DWARFDebugInfoEntry *die,
const lldb_private::ConstString &type_name);
This function isn't used as it has been replaced by:
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (
const DWARFDeclContext &die_decl_ctx);
I am about to change the way we resolve C/C++ class/struct/union types and want to clean up SymbolFileDWARF before I start.
llvm-svn: 223376
This was fixed by making the DWARFFormValue contain the compile unit that it needs so it can decode its form value correctly. Any form value that requires a compile unit will now assert. If any of the assertions that were added are triggered, then code that led to the extraction of the form value without properly setting the compile unit must be fixed immediately.
<rdar://problem/19035440>
llvm-svn: 222602
1. DW_FORM_strp and DW_FORM_sec_offset are 64bits for DWARF64 / 32bits for DWARF32
They are different from DW_FORM_addr, whose size is specified in .debug_info
2. Bump DWARF version support form [2,3] to [2,4] in DWARFDebugLine.cpp
3. Fix DWARFDebugLine to support DWARF64
See http://reviews.llvm.org/D5307 for more details.
Reviewed by Greg Clayton and Jason Molenda.
Change by Tong Shen.
llvm-svn: 217607
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
This fix reduces the stack size of SymbolFileDWARF::ParseType(). It seems that clang is not very good at sharing locations on the stack with local variables in large functions that have many blocks and each variable gets unique locations. The reduction in size was done by:
1 - removing some large locals that were default constructed by not used
2 - Placing some larger local variables into std::unique_ptr<> to make them on the heap
3 - removing local variables there were large and being populated but not being used
4 - reducing the size of some typedefs to llvm::SmallVector<T, N> so that N wasn’t excessively large
<rdar://problem/16431645>
llvm-svn: 205640
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
<rdar://problem/15594781>
We need to not crash at any cost. We currently detect if any base classes are forward declarations, emit an error string that directs the use to file a compiler bug, and continues by completing the class with no contents. This avoids a clang crash that would usually follow when we call setBase().
llvm-svn: 197108
To make this work this patch extends LLDB to:
- Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list.
- Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines.
- Make DWARF expressions track which module they originated from.
- Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here.
- Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here:
1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target.
2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out.
3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized.
However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used.
Test case included.
llvm-svn: 192922
that all clients use them explicitly. This will hopefully
prevent any future confusion where things get cast to types
we don't expect.
<rdar://problem/15146458>
llvm-svn: 191984
to be explicit, to prevent horrid things like
std::string a = ConstString("foo")
from taking the path ConstString -> bool -> char
-> std::string.
This fixes, among other things, ClangFunction.
<rdar://problem/15137989>
llvm-svn: 191934
Fixed an issue with the lldb/test/lang/cpp/virtual test case had a virtual class that had a DW_TAG_inheritance child that was virtual and had a DW_AT_data_member_location of:
DW_AT_data_member_location( DW_OP_dup, DW_OP_deref, DW_OP_constu(0x00000018), DW_OP_minus, DW_OP_deref, DW_OP_plus )
We failed to evaluate this and then we were passing the incorrect offset back to clang and clang would crash. The AST external source has a function named LayoutRecordType which allows us to supply the virtual base class offsets, but that really doesn't make sense to do as clang will lay them out correctly. So we must ignore virtual base classes when doing layout.
llvm-svn: 190811
Greg Clayton