summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol
Commit message (Collapse)AuthorAgeFilesLines
...
* Made templates that have Enumeration values as arguments work correctly.Greg Clayton2016-06-242-0/+31
| | | | | | | | | | We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types. Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix. Also added a test case to ensure this doesn't regress in the future. llvm-svn: 273750
* The Objective-C Class type should not be treated as a potential dynamic ↵Enrico Granata2016-06-241-0/+8
| | | | | | | | type, since it actually doesn't resolve to the type of the class it points to Fixes rdar://26535584 llvm-svn: 273721
* Silence a -Wc++11-narrowing warningDavid Majnemer2016-06-241-1/+1
| | | | llvm-svn: 273649
* Update LLDB for r273647David Majnemer2016-06-241-4/+2
| | | | llvm-svn: 273648
* Handle variadic Objective-C methods from DWARF correctly.Sean Callanan2016-06-241-2/+2
| | | | | | <rdar://problem/22039804> llvm-svn: 273632
* Add support for using armv7 compact unwind informationJason Molenda2016-06-072-54/+319
| | | | | | | | | | | | | | | as an asynchronous unwind plan source. Two small fixes to the compact unwind dumper tool for armv7 encodings. A change to DWARFCallFrameInfo to strip the 0th bit on addresses in eh_frame sections when armv7. In the clang generated examples I have, the 0th bit is set for thumb functions and that's causing the unwinder to pick the wrong function for eh_frame info. llvm-svn: 271970
* With -gmodules, we have been having a harder time always finding a type when ↵Greg Clayton2016-05-261-2/+25
| | | | | | | | | | | | | | | | | | | | | | we need one. We have seen cases where we have been unable to find an argument type for a function, or we find one from another language, and then we try to create a function type by calling: lldb_private::ClangASTContext::CreateFunctionType(clang::ASTContext*, lldb_private::CompilerType const&, lldb_private::CompilerType const*, unsigned int, bool, unsigned int) This fix will ensure that all arguments to lldb_private::ClangASTContext::CreateFunctionType() are in order by checking: - AST is valid - if arguments are specified we have a valid argument array - return type is valid - return type is a clang type - all argument types are valid - all argument types are clang types If any of these fail, we return an invalid CompilerType. If we don't return an invalid type, clang will crash anyway, and LLDB must not crash even in the presence of bad or missing debug info. <rdar://problem/25172715> llvm-svn: 270932
* Make sure that we succeed in starting a definition before we complete it and ↵Greg Clayton2016-05-261-10/+20
| | | | | | | | | | | | | | | | emit an error if we fail to start the definition. ClangASTContext::StartTagDeclarationDefinition(...) was starting definitions for any TagType instances that have TagDecl, but ClangASTContext::CompleteTagDeclarationDefinition(...) was getting the type to a CXXRecordDecl with: clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl(); The problem is that getAsCXXRecordDecl() might dig a bit deeper into a type and dig out a different decl, which means we might call ClangASTContext::StartTagDeclarationDefinition(...), but it might not do anything, and then we might call ClangASTContext::CompleteTagDeclarationDefinition(...) and it might try to complete something that didn't have its definition started and this will crash. This change fixes that, and also makes sure that starting a definition succeeds before any calls to ClangASTContext::CompleteTagDeclarationDefinition(). <rdar://problem/24091798> llvm-svn: 270891
* Add support for arm64 compact unwind tables, used on darwin arm64Jason Molenda2016-05-251-0/+188
| | | | | | | | | | | | | | systems (ios, tvos, watchos). It's a simple format to use now that I have i386/x86_64 supported already. The unwind instructions are only valid at call sites -- that is, when lldb is unwinding a frame in the middle of the stack. It cannot be used for the currently executing frame; it has no information about prologues/epilogues/etc. <rdar://problem/12062336> llvm-svn: 270658
* Removed the m_decl_objects map from ClangASTContext.Sean Callanan2016-05-234-43/+1
| | | | | | | | | | | | | m_decl_objects is problematic because it assumes that each VarDecl has a unique variable associated with it. This is not the case in inline contexts. Also the information in this map can be reconstructed very easily without maintaining the map. The rest of the testsuite passes with this cange, and I've added a testcase covering the inline contexts affected by this. <rdar://problem/26278502> llvm-svn: 270474
* Fix build after rL270009Tamas Berghammer2016-05-191-1/+0
| | | | llvm-svn: 270040
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-196-73/+65
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-183-58/+58
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Symbol: fix -Wcovered-switch warningSaleem Abdulrasool2016-05-151-101/+107
| | | | | | | Add the Float128 type to the enumeration. Float128 is covered under IEEE754 as a quad precision floating point value. llvm-svn: 269599
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-113-3/+19
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* Add support for displaying Java array types on AndoridTamas Berghammer2016-05-051-58/+106
| | | | | | Differential revision: http://reviews.llvm.org/D19540 llvm-svn: 268622
* Intentionally leak the ASTSourceMap instead of destroying it when LLDB quits.Sean Callanan2016-05-041-2/+3
| | | | | | <rdar://problem/25959792> llvm-svn: 268559
* Add a way for an ObjectFile to indicate that assembly emulationJason Molenda2016-05-042-1/+11
| | | | | | | | | | | | | | | | | | | | | should not be used for this module -- for use when an ObjectFile knows that it does not have meaningful or accurate function start addresses. More commonly, it is not clear that function start addresses are missing in a module. There are certain cases on Mac OS X where we can tell that a Mach-O binary has been stripped of this essential information, and the unwinder can end up emulating many megabytes of instructions for a single "function" in the binary. When a Mach-O binary is missing both an LC_FUNCTION_STARTS load command (very unusual) and an eh_frame section, then we will assume it has also been stripped of symbols and that instruction emulation will not be useful on this module. <rdar://problem/25988067> llvm-svn: 268475
* You have to call setHasLoadedFieldsFromExternalStorage AFTER callingJim Ingham2016-05-041-1/+1
| | | | | | | | | | | the field_begin that starts the copy or it won't do anything. This causes failures, but only in complex apps, I haven't found a reduced test case for this yet. <rdar://problem/21951798> llvm-svn: 268467
* Import block pointers from DWARF as Clang block pointers, not as structs.Sean Callanan2016-05-024-4/+95
| | | | | | | | | Also added a data formatter that presents them as structs if you use frame variable to look at their contents. Now the blocks testcase works. <rdar://problem/15984431> llvm-svn: 268307
* Make sure LLDB can deal with forward declarations to enums without crashing ↵Greg Clayton2016-04-291-15/+19
| | | | | | | | or asserting. <rdar://problem/23776428> llvm-svn: 268098
* Committing patch from <Michael Woerister <michaelwoerister@posteo.net>Jason Molenda2016-04-271-0/+2
| | | | | | | | | | | to use the default clang C/C++ expression parser when debugging Rust programs. Ideally there would be a rust language plugin to support their language natively, but until then this will get simple variable display to work. http://reviews.llvm.org/D19545 llvm-svn: 267667
* Fixed in issue with ObjectFileMachO where it would add empty sections to the ↵Greg Clayton2016-04-221-5/+8
| | | | | | | | section list that was used to try and cap symbols to the max address of the section in which it is contained. The empty sections would make cap the symbols and make their sizes zero. Also fixed a few other things that could cause problems in the SymbolFileDWARFDebugMap when zero sized symbols were found and used to make OSO range map entries. <rdar://problem/25886773> llvm-svn: 267237
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-11/+4
| | | | | | | | | | | | | Recommit modified version of r266311 including build bot regression fix. This differs from the original r266311 by: - Fixing Scalar::Promote to correctly zero- or sign-extend value depending on signedness of the *source* type, not the target type. - Omitting a few stand-alone fixes that were already committed separately. llvm-svn: 266422
* Initial support for reading type information from PDBs.Zachary Turner2016-04-151-2/+30
| | | | | | | | | | | | | | | | This implements a PDBASTParser and corresponding logic in SymbolFilePDB to do type lookup by name. This is just a first pass and leaves many aspects of type lookup unimplemented, and just focuses on laying the framework. With this patch, you should be able to lookup basic types by name from a PDB. Full class definitions are not completed yet, we will instead just return a forward declaration of the class. Differential Revision: http://reviews.llvm.org/D18848 Reviewed by: Greg Clayton llvm-svn: 266392
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-4/+11
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Miscellaneous fixes for big-endian systemsUlrich Weigand2016-04-141-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scalar implementation and a few other places in LLDB directly access the internal implementation of APInt values using the getRawData method. Unfortunately, pretty much all of these places do not handle big-endian systems correctly. While on little-endian machines, the pointer returned by getRawData can simply be used as a pointer to the integer value in its natural format, no matter what size, this is not true on big-endian systems: getRawData actually points to an array of type uint64_t, with the first element of the array always containing the least-significant word of the integer. This means that if the bitsize of that integer is smaller than 64, we need to add an offset to the pointer returned by getRawData in order to access the value in its natural type, and if the bitsize is *larger* than 64, we actually have to swap the constituent words before we can access the value in its natural type. This patch fixes every incorrect use of getRawData in the code base. For the most part, this is done by simply removing uses of getRawData in the first place, and using other APInt member functions to operate on the integer data. This can be done in many member functions of Scalar itself, as well as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter, I've had to add a Scalar::MakeUnsigned routine to parallel the existing Scalar::MakeSigned, e.g. in order to implement an unsigned divide. The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong were already unused and can be simply removed. I've also removed the Scalar::GetRawBits64 function and its few users. The one remaining user of getRawData in Scalar.cpp is GetBytes. I've implemented all the cases described above to correctly implement access to the underlying integer data on big-endian systems. GetData now simply calls GetBytes instead of reimplementing its contents. Finally, two places in the clang interface code were also accessing APInt.getRawData in order to actually construct a byte representation of an integer. I've changed those to make use of a Scalar instead, to avoid having to re-implement the logic there. The patch also adds a couple of unit tests verifying correct operation of the GetBytes routine as well as the conversion routines. Those tests actually exposed more problems in the Scalar code: the SetValueFromData routine didn't work correctly for 128- and 256-bit data types, and the SChar routine should have an explicit "signed char" return type to work correctly on platforms where char defaults to unsigned. Differential Revision: http://reviews.llvm.org/D18981 llvm-svn: 266311
* Fixes for platforms that default to unsigned charUlrich Weigand2016-04-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This fixes several test case failure on s390x caused by the fact that on this platform, the default "char" type is unsigned. - In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return an explicit *signed* char type for encoding eEncodingSint and bit size 8, instead of the default platform char type (which may be unsigned). This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize, and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize unit test case. - The test/expression_command/char/TestExprsChar.py test case is known to fail on platforms defaulting to unsigned char (pr23069), and just needs to be xfailed on s390x like on arm. - The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test case defines a vector of "char" and implicitly assumes to be signed. Use an explicit "signed char" instead. Differential Revision: http://reviews.llvm.org/D18979 llvm-svn: 266309
* Match types in for loop to fix signedness comparison warningEd Maste2016-04-131-2/+2
| | | | llvm-svn: 266197
* Update Symtab::InitAddressIndexes so that computed symbol sizesJason Molenda2016-04-131-12/+93
| | | | | | | | | | | | | will not exceed the bounds of their Section. This is addressing a problem where a file had a large space between two sections that were not used by this module - the last symbol in the text section had an enormous size because the distance between that and the first symbol in the data section were used to compute the size. http://reviews.llvm.org/D19004 <rdar://problem/25227945> llvm-svn: 266165
* Fixed Variable::GetDecl() and Variable::GetDeclContext() to check the "Type ↵Greg Clayton2016-04-121-4/+10
| | | | | | | | *" before using it so we don't crash if a variable's type can't be realized which happens more often recently due to -gmodules. <rdar://problem/25612626> llvm-svn: 266023
* Fix-up LLDB build after rL13179Tamas Berghammer2016-04-081-18/+54
| | | | llvm-svn: 265787
* Symbol: fix buildSaleem Abdulrasool2016-04-071-2/+2
| | | | | | | TargetOptions is ambiguous due to a definition in LLVM and in clang. This was exposed by SVN r265640. Update to fix the build against the newer revision. llvm-svn: 265644
* Add some unit tests for ClangASTContext.Zachary Turner2016-04-012-129/+90
| | | | | | | | | | | In doing so, two bugs were uncovered (and fixed). The first bug is that ClangASTContext::RemoveFastQualifiers() was broken, and was not removing fast qualifiers (or doing anything else for that matter). The second bug is that UnifyAccessSpecifiers treated AS_None asymmetrically, which is probably an edge case, but seems like a bug nonetheless. llvm-svn: 265200
* When creating typedefs, don't call Type::GetName() since that might ↵Greg Clayton2016-03-291-4/+4
| | | | | | | | recursively call "lldb_private::Type::ResolveClangType(lldb_private::Type::ResolveStateTag)" and cause a crash. A lldb_private::Type should have a valid name if it is created without a backing CompilerType. Also provide a name that we can recognize so if we see it in a as the typename of a variable, we will know to check it out. This crash is happening quite a bit and we need to determine if this is due to incorrect debug info, or just due to some bug in LLDBD. <rdar://problem/25192037> llvm-svn: 264762
* Don't try to call getTypeSize() on a class if it isn't complete as clang ↵Greg Clayton2016-03-291-1/+9
| | | | | | will assert and kill the process. llvm-svn: 264753
* Move some functions from DWARFASTParserClang to ClangASTImporter.Zachary Turner2016-03-284-347/+402
| | | | | | | | | | | | | | | | | | This allows these functions to be re-used by a forthcoming PDBASTParser. The functions in question are CanCompleteType, CompleteType, and CanImport. Conceptually, these functions belong on ClangASTImporter anyway, and previously they were just ping ponging around through a few levels of indirection to end up there as well, so this patch actually makes the code somewhat simpler. A few methods were moved to a new file called ClangUtil, so that they can be shared between ClangASTImporter and ClangASTContext without creating a circular dependency between those two cpp files. Differential Revision: http://reviews.llvm.org/D18381 llvm-svn: 264685
* When we import the definition for a Tagdecl, propagate its completeness too.Sean Callanan2016-03-261-3/+14
| | | | | | | | | | | The ASTImporter completes the full definiton for a TagDecl in several places, including the type-deport logic. When this happens, we should also propagate the bit that says that this is a complete definition. This makes (for example) lambdas callable. <rdar://problem/22864976> llvm-svn: 264485
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Fix ClangASTContext::GetFunctionArgumentAtIndex() to not water down the type ↵Greg Clayton2016-03-151-1/+1
| | | | | | to the canonical type before handing the type out for the function type. llvm-svn: 263601
* Fix expression evaluation for resolving anonymous aggregrate types with a ↵Ewan Crawford2016-03-151-0/+14
| | | | | | | | | | | | | | | | | typedefed name This fixes a recently reported a bug(https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the clang expression evaluator no longer being able to resolve calls to functions with arguments to typedefed anonymous structs, unions, or enums after a cleanup to the expression parsing code in r260768 This fixes the issue by attaching the tagged name to the original clang::TagDecl object when generating the typedef in lldb::ClangAstContext::CreateTypeDef. This also fixes the issue for anonymous typedefs for non-struct types (unions and enums) where we have a tag name. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D18099 llvm-svn: 263544
* Fix compiler warnings in the java codePavel Labath2016-02-291-3/+1
| | | | llvm-svn: 262214
* Fix address class lookup for absolute symbolsTamas Berghammer2016-02-261-1/+5
| | | | llvm-svn: 262016
* Add a set of new plugins to handle Java debuggingTamas Berghammer2016-02-262-0/+1521
| | | | | | | | | The purpose of these plugins is to make LLDB capable of debugging java code JIT-ed by the android runtime. Differential revision: http://reviews.llvm.org/D17616 llvm-svn: 262015
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-262-2/+2
| | | | | | the right thing and break. llvm-svn: 261950
* Add support for handling absolute symbols in ELFTamas Berghammer2016-02-251-0/+1
| | | | | | | | | | | | | | | Most address represented in lldb as section plus offset and handling of absolute addresses is problematic in several location because of lack of necessary information (e.g. Target) or because of performance issues. This CL change the way ObjectFileELF handle the absolute symbols with creating a pseudo section for each symbol. With this change all existing code designed to work with addresses in the form of section plus offset will work with absolute symbols as well. Differential revision: http://reviews.llvm.org/D17450 llvm-svn: 261859
* Handle the case when a variable is only valid in part of the enclosing scopeTamas Berghammer2016-02-252-11/+44
| | | | | | | | | | | DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
* Fix test for homogeneity in case of aggregate consisting of containerized ↵Omair Javaid2016-02-241-13/+14
| | | | | | | | | | vector types Details can be found here: Differential revision: http://reviews.llvm.org/D17501 llvm-svn: 261734
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-183-90/+54
| | | | | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
OpenPOWER on IntegriCloud