summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
* Fix an issue where the apropos command would not print fully qualified ↵Enrico Granata2016-05-021-1/+1
| | | | | | | | command names for nested command objects rdar://problem/26020072 llvm-svn: 268309
* Import block pointers from DWARF as Clang block pointers, not as structs.Sean Callanan2016-05-029-4/+420
| | | | | | | | | 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
* Add more debug logging to g_get_shared_cache_class_info_bodyEnrico Granata2016-05-021-1/+14
| | | | llvm-svn: 268303
* Add an argument to ValueObject::GetSyntheticBase that allows for name ↵Enrico Granata2016-05-021-4/+10
| | | | | | customization on the generated value llvm-svn: 268274
* Add support for synthetic child providers to optionally return a customized ↵Enrico Granata2016-05-024-0/+80
| | | | | | typename for display llvm-svn: 268208
* Improve wording and capitalization of TSan thread names.Kuba Brecka2016-05-011-7/+7
| | | | llvm-svn: 268193
* Add thread numbers into ASan thread names.Kuba Brecka2016-05-011-5/+8
| | | | llvm-svn: 268192
* Watch out for compilers that generate bad bitfield info. If the bit size of ↵Greg Clayton2016-04-291-1/+18
| | | | | | | | | a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information. https://llvm.org/bugs/show_bug.cgi?id=27515 <rdar://problem/21082998> llvm-svn: 268110
* Fix TestGetVariables.py so it works correctly. We had duplicate static ↵Greg Clayton2016-04-291-1/+9
| | | | | | values showing up as we would find static variables in the Block and also in the compile unit. We now make sure a variable hasn't been added to the list before we add it. llvm-svn: 268101
* Make sure LLDB can deal with forward declarations to enums without crashing ↵Greg Clayton2016-04-292-18/+31
| | | | | | | | or asserting. <rdar://problem/23776428> llvm-svn: 268098
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-294-9/+17
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 268083
* Used llvm_unreached to quite a VC++ compiler warning.Adrian McCarthy2016-04-281-0/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D19489 llvm-svn: 267931
* Provide location information (file name, line number) in TSan reports about ↵Kuba Brecka2016-04-282-3/+45
| | | | | | global variables. llvm-svn: 267894
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-285-85/+9
| | | | | | | | | | $__lldb_expr." This reverts commit r267833 as it breaks the build. It looks like some work in progress got committed together with the actual fix, but I'm not sure which one is which, so I'll revert the whole patch and let author resumbit it after fixing the build error. llvm-svn: 267861
* Fix an inefficiency in the handling of $__lldb_local_vars in expressions.Jim Ingham2016-04-282-1/+3
| | | | | | | | | | | | | | The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token means, and adds the namespace to the lookup context, but since it doesn't mark it as special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource for further lookup. Unless we've done our job wrong, those lookups will always fail, but the can be costly. So I added a bit to m_found & use that to short-circuit the lookup. <rdar://problem/25613384> llvm-svn: 267842
* Add the ability to limit "source regexp" breakpoints to a particular functionJim Ingham2016-04-285-33/+93
| | | | | | | | | | | | within a source file. This isn't done, I need to make the name match smarter (right now it requires an exact match which is annoying for methods of a class in a namespace. Also, though we use it in tests all over the place, it doesn't look like we have a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch. llvm-svn: 267834
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-285-9/+85
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 267833
* Renamed system plugin directory to address https://bugs.swift.org/browse/SR-1093Kate Stone2016-04-271-1/+1
| | | | llvm-svn: 267749
* Use absolute module path when possible if sent in svr4 packetsFrancis Ricci2016-04-271-8/+1
| | | | | | | | | | | | | | | | | | | | | Summary: If the remote uses svr4 packets to communicate library info, the LoadUnload tests will fail, as lldb only used the basename for modules, causing problems when two modules have the same basename. Using absolute path as sent by the remote will ensure that lldb locates the module from the correct directory when there are overlapping basenames. When debugging a remote process, LoadModuleAtAddress will still fall back to using basename and module_search_paths, so we don't need to worry about using absolute paths in this case. Reviewers: ADodds, jasonmolenda, clayborg, ovyalov Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19557 llvm-svn: 267741
* 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
* UtilityFunction::MakeFunctionCaller uses the Error to report failure,Jim Ingham2016-04-261-0/+3
| | | | | | | | but when there's was no process it was just returning an null pointer and not setting the error. I don't have a scenario where this might go wrong, just code inspection... llvm-svn: 267594
* rL267291: Architecture change to thumb on parsing arm.attributes causes ↵Omair Javaid2016-04-261-13/+0
| | | | | | | | | | regression. Remove case handling elf arm attribute Tag_THUMB_ISA_use and setting architecture to thumb. Differential revision: http://reviews.llvm.org/D19520 llvm-svn: 267550
* Fix arm-linux-gnueabi regression due to rL267291Omair Javaid2016-04-261-1/+5
| | | | | | | | | | | | rL267291 introduces a lot regression on arm-linux LLDB testsuite. This patch fixes half of them. I am merging it under already revied android counterpart. Another patch fixing rest of the issue will follow this commit. Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267508
* When building the list of variables we're going to write "using ↵Jim Ingham2016-04-262-3/+6
| | | | | | | | | $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
* Make sure that the following SymbolFileDWARF functions can handle getting a ↵Greg Clayton2016-04-252-9/+57
| | | | | | | | | | | | | | | | | | | | lldb::user_id_t for another SymbolFileDWARF: CompilerDecl SymbolFileDWARF::GetDeclForUID (lldb::user_id_t type_uid); CompilerDeclContext SymbolFileDWARF::GetDeclContextForUID (lldb::user_id_t type_uid) CompilerDeclContext SymbolFileDWARF::GetDeclContextContainingUID (lldb::user_id_t type_uid) Type* SymbolFileDWARF::ResolveTypeUID (lldb::user_id_t type_uid) <rdar://problem/25592223> llvm-svn: 267494
* Fix StackFrame::GetVariables(...) function that was broken by 261858 when ↵Greg Clayton2016-04-251-1/+1
| | | | | | | | lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. llvm-svn: 267478
* Maintain register numbering across xml include featuresFrancis Ricci2016-04-251-6/+7
| | | | | | | | | | | | | | | | | | Summary: If the remote uses include features when communicating xml register info back to lldb, the existing code would reset the lldb register index at the beginning of each include node. This would lead to multiple registers having the same lldb register index. Since the lldb register numbers should be contiguous and unique, maintain them accross the parsing of all of the xml feature nodes. Reviewers: jingham, jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19303 llvm-svn: 267468
* Properly unload modules from target image list when using svr4 packetsFrancis Ricci2016-04-251-2/+24
| | | | | | | | | | | | | | | | | | | Summary: When we receive an svr4 packet from the remote, we check for new modules and add them to the list of images in the target. However, we did not do the same for modules which have been removed. This was causing TestLoadUnload to fail when using ds2, which uses svr4 packets to communicate all library info on Linux. This patch fixes the failing test. Reviewers: zturner, tfiala, ADodds Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19230 llvm-svn: 267467
* Use Process Plugin register indices when communicating with remoteFrancis Ricci2016-04-252-8/+9
| | | | | | | | | | | | | | | | | | Summary: eRegisterKindProcessPlugin is used to store the register indices used by the remote, and eRegisterKindLLDB is used to store the internal lldb register indices. However, we're currently using the lldb indices instead of the process plugin indices when sending p/P packets. This will break if the remote uses non-contiguous register indices. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19305 llvm-svn: 267466
* Fix ARM attribute parsing for Android after rL267291Tamas Berghammer2016-04-252-14/+26
| | | | | | Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
* Handle invalid values of PLT entry size generated by linkerOmair Javaid2016-04-251-1/+4
| | | | | | | | Make sure we figure out correct plt entry field in case linker has generated a small value below realistic entry size like 4 bytes or below. Differential revision: http://reviews.llvm.org/D19252 llvm-svn: 267405
* Add a --element-count option to the expression commandEnrico Granata2016-04-255-13/+82
| | | | | | | | | | | | | This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements This has a couple subtle points but is mostly as straightforward as it sounds Add a parray N <expr> alias for this new mode Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode Add a poarray N <expr> alias for this llvm-svn: 267372
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-242-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt to detect and handle the case where the PC points beyond the end of a function, but there are certain cases where this doesn't work correctly. In fact, there are *two* different places where this detection is attempted, and the failure is in fact a result of an unfortunate interaction between those two separate attempts. First, the ResolveSymbolContextForAddress routine is called with the resolve_tail_call_address flag set to true. This causes the routine to internally accept a PC pointing beyond the end of a function, and still resolving the PC to that function symbol. Second, the InitializeNonZerothFrame routine itself maintains a "decr_pc_and_recompute_addr_range" flag and, if that turns out to be true, itself decrements the PC by one and searches again for a symbol at that new PC value. Both approaches correctly identify the symbol associated with the PC. However, the problem is now that later on, we also need to find the DWARF CFI record associated with the PC. This is done in the RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses the "m_current_offset_backed_up_one" member variable. However, that variable only actually contains the PC "backed up by one" if the *second* approach above was taken. If the function was already identified via the first approach above, that member variable is *not* backed up by one but simply points to the original PC. This in turn causes GetEHFrameUnwindPlan to not correctly identify the DWARF CFI record associated with the PC. Now, in many cases, if the first method had to back up the PC by one, we *still* use the second method too, because of this piece of code: // Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp), // and our "current" pc is the start of a function... if (m_sym_ctx_valid && GetNextFrame()->m_frame_type != eTrapHandlerFrame && GetNextFrame()->m_frame_type != eDebuggerFrame && addr_range.GetBaseAddress().IsValid() && addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection() && addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset()) { decr_pc_and_recompute_addr_range = true; } In many cases, when the PC is one beyond the end of the current function, it will indeed then be exactly at the start of the next function. But this is not always the case, e.g. if there happens to be alignment padding between the end of one function and the start of the next. In those cases, we may sucessfully look up the function symbol via ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range, and therefore fail to find the correct DWARF CFI record. A very simple fix for this problem is to just never use the first method. Call ResolveSymbolContextForAddress with resolve_tail_call_address set to false, which will cause it to fail if the PC is beyond the end of the current function; or else, identify the next function if the PC is also at the start of the next function. In either case, we will then set the decr_pc_and_recompute_addr_range variable and back up the PC anyway, but this time also find the correct DWARF CFI. A related problem is that the ResolveSymbolContextForAddress sometimes returns a "symbol" with empty name. This turns out to be an ELF section symbol. Now, usually those get type eSymbolTypeInvalid. However, there is code in ObjectFileELF::ParseSymbols that tries to change the type of invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol lies within the code or data section. Unfortunately, this check also hits the symbol for the code section itself, which is then marked as eSymbolTypeCode. While the size of the section symbol is 0 according to the ELF file, LLDB considers this size invalid and attempts to figure out the "correct" size. Depending on how this goes, we may end up with a symbol that overlays part of the code section, even outside areas covered by real function symbols. Therefore, if we call ResolveSymbolContextForAddress with PC pointing beyond the end of a function, we may get this bogus section symbol. This again means InitializeNonZerothFrame thinks we have a valid PC, but then we don't find any unwind info for it. The fix for this problem is me to simply always leave ELF section symbols as type eSymbolTypeInvalid. Differential Revision: http://reviews.llvm.org/D18975 llvm-svn: 267363
* ObjectFile: parse EABI AttributesSaleem Abdulrasool2016-04-232-0/+104
| | | | | | | | This adds basic parsing of the EABI attributes section. This section contains additional information about the target for which the file was built. Attempt to infer additional architecture information from that section. llvm-svn: 267291
* DWARF layout for bitfields is wrong when the bit offset is negative. Greg Clayton2016-04-221-3/+3
| | | | | | | | Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress. <rdar://problem/21082998> llvm-svn: 267248
* Source: fix another -Wunused-variable warningSaleem Abdulrasool2016-04-221-0/+2
| | | | | | | Conditionalise a variable definition which may be unused in certain compilations due to the preprocessor. Protect the variable accordingly. NFC. llvm-svn: 267247
* Fixed in issue with ObjectFileMachO where it would add empty sections to the ↵Greg Clayton2016-04-223-8/+22
| | | | | | | | 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
* Renumber ThreadSanitizer-provided thread IDs to match LLDB thread numbers.Kuba Brecka2016-04-221-17/+47
| | | | llvm-svn: 267133
* Update Go OS Plugin for newer runtimes.Ryan Brown2016-04-211-2/+13
| | | | | | Differential Revision: http://reviews.llvm.org/D19273 llvm-svn: 267048
* API: fix a -Wunused-variable warningSaleem Abdulrasool2016-04-211-0/+2
| | | | | | | expr_log is only conditionally used via preprocessing. Ensure that we guard the definition accordingly. NFC. llvm-svn: 267001
* Host: fix some -Wformat-pedantic warningsSaleem Abdulrasool2016-04-211-6/+6
| | | | | | Add explicit casts for function pointer to void * for %p conversion. NFC. llvm-svn: 267000
* Expressions can run without a process.Jim Ingham2016-04-211-17/+30
| | | | | | | | | | | Code was added in ClangExpressionParser::ClangExpressionParser that was calling through the process w/o checking that it was good. Also, we were pretending that we could do something reasonable if we had no target, but that's actually not true, so I check for a target at the beginning of the constructor and don't make a compiler in that case. <rdar://problem/25841198> llvm-svn: 266944
* Corrected wording of REPL not available messaging (contained a repeated word ↵Kate Stone2016-04-212-2/+2
| | | | | | and lacked clarity.) llvm-svn: 266941
* Added command prefix to new help messages to ensure that they're correctly ↵Kate Stone2016-04-211-11/+5
| | | | | | words in REPL mode. llvm-svn: 266940
* When making an array or stuct/union/class elements, make sure the type is ↵Greg Clayton2016-04-201-1/+28
| | | | | | | | complete. If the type isn't complete, complete the type so that clang won't assert and kill your program. Since the DWARF assists in doing layout, it won't show the array or struct/unions/class elements correctly, but it will stop you from crashing if you have a struct/union/class that contains one of these arrays. <rdar://problem/25057391> llvm-svn: 266922
* Fix a bug where LLDB would crash if 'apropos <anything>' was used after ↵Enrico Granata2016-04-202-1/+10
| | | | | | spawning an inferior process llvm-svn: 266911
* llvm::sys::path::home_directory() relies on having "HOME" set in the ↵Greg Clayton2016-04-191-1/+15
| | | | | | | | | | environment and that might not always be set. Our FileSpec class uses this function to resolve any paths that start with "~/" on systems that support home directories as '~'. I have modified FileSpec::ResolveUsername (llvm::SmallVectorImpl<char> &path) to deal with the cases where llvm::sys::path::home_directory() returns false by digging a little further on unix systems and setting "HOME" in the environment so that subsequent calls to llvm::sys::path::home_directory() will succeed. I also added a test to ensure we don't regress. <rdar://problem/25342377> llvm-svn: 266832
* Revert "LLDB: Fixed two race conditions when stopping private state thread"Pavel Labath2016-04-191-4/+8
| | | | | | This reverts commit r266733 as it causes a number of failures on linux buildbots. llvm-svn: 266736
* LLDB: Fixed two race conditions when stopping private state threadMarianne Mailhot-Sarrasin2016-04-191-8/+4
| | | | | | | | | | | | | | When stopping the private state thread, there was a race condition between the time the thread exits (resetting the HostThread object) and the time a Join was attempted, especially in the case of a timeout. The previous workaround of copying the HostThread object is not enough, since on a Reset the internal thread stuff gets nulled out regardless of which HostThread object actually has Reset called on it, resulting in an attempt to dereference a null pointer on the subsequent call to Join from the copy as well. Additionally, there was a race between the detach (called when stopping the process) and the stop itself, causing the stop to time out because it was waiting for the private state thread to see the stop state, but it had exited immediately after entering the detached state. Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19122 llvm-svn: 266733
* Fix Windows build.Chaoren Lin2016-04-191-0/+1
| | | | llvm-svn: 266702
OpenPOWER on IntegriCloud