summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* Fix TestEnumTypes.py for 32 bit platforms.Chaoren Lin2016-04-291-2/+2
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19751 llvm-svn: 268135
* Watch out for compilers that generate bad bitfield info. If the bit size of ↵Greg Clayton2016-04-292-2/+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-294-19/+50
| | | | | | | | 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-298-10/+52
| | | | | | | | | | | | | | | | | | | 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
* XFail TestBitfields.py Python API tests.Chaoren Lin2016-04-281-0/+1
| | | | | | | | | | | | | | Summary: Started failing after rL267895. Possibly related to http://llvm.org/pr27510. Reviewers: labath, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19680 llvm-svn: 267923
* Provide location information (file name, line number) in TSan reports about ↵Kuba Brecka2016-04-285-3/+143
| | | | | | global variables. llvm-svn: 267894
* Remote flaky decorator from TestSignalsAPI on linuxPavel Labath2016-04-281-1/+0
| | | | | | | The test seems to pass now, and the test does not seem to be doing anything unusual, so I don't expect it to cause problems. llvm-svn: 267867
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-288-120/+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-2810-34/+118
| | | | | | | | | | | | 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-288-9/+120
| | | | | | | | | | | | | | | | | | | 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
* XFail TestIRInterpreter on WindowsAdrian McCarthy2016-04-271-0/+1
| | | | | | | | There's an open bug with calling functions in the inferior. And Windows doesn't have the POSIX function getpid(). Differential Revision: http://reviews.llvm.org/D19626 llvm-svn: 267800
* Added a testcase for the IR interpreter, ensuring that it behaves like the JIT.Sean Callanan2016-04-273-0/+84
| | | | | | <rdar://problem/25785338> llvm-svn: 267768
* 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
* Decorate TSan tests with "@skipUnlessThreadSanitizer" which skips the tests ↵Kuba Brecka2016-04-275-0/+22
| | | | | | if the selected compiler can't compile with "-fsanitize=thread". llvm-svn: 267726
* Remove flaky decorator from three tests on linuxPavel Labath2016-04-273-3/+0
| | | | | | The flakyness is no longer reproducible, and the tests seem to be passing reliably now. llvm-svn: 267704
* Fix compiler warnings in SymbolFilePDBTestsPavel Labath2016-04-271-20/+20
| | | | llvm-svn: 267688
* 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
* Fix TestRegisterVariables.py on WindowsAdrian McCarthy2016-04-261-3/+3
| | | | | | | | Use __attribute__((regparm(x))) to ensure the compiler enregisters at least some arguments when calling functions. Differential Revision: http://reviews.llvm.org/D19548 llvm-svn: 267616
* 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
* Fix send and receive of ACK byte in test infrastructure for Python 3.5Adrian McCarthy2016-04-262-6/+2
| | | | | | | | Python 3.5 is pickier about the distinction between chars and bytes (and strings and bytearrays) than Python 2.7. Differential Revision: http://reviews.llvm.org/D19510 llvm-svn: 267562
* Bump up timeout in TestCallWithTimeoutPavel Labath2016-04-261-2/+2
| | | | | | Expression very rarely (linux buildbot, build 13907) completed before we managed to interrupt it. llvm-svn: 267554
* 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-263-4/+7
| | | | | | | | | $_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 TestGetVariables.py.Chaoren Lin2016-04-252-2/+3
| | | | | | | | | | Reviewers: sivachandra, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19511 llvm-svn: 267492
* Fix StackFrame::GetVariables(...) function that was broken by 261858 when ↵Greg Clayton2016-04-254-1/+224
| | | | | | | | 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
* Store absolute path for lldb executable in dotest.pyFrancis Ricci2016-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: lldb-server tests are currently being skipped on the check-lldb target. This is because we get the path of lldb-server by modifying the path to the lldb executable. However, by this point, we've changed directories, and a relative path to the build/bin directory will no longer point to the location of lldb-server. Storing an absolute path solves this issue. Reviewers: vharron, zturner, tfiala, labath Subscribers: labath, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19082 llvm-svn: 267463
* Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is usedFrancis Ricci2016-04-253-10/+45
| | | | | | | | | | | | | | | | Summary: Do not assume that liblldb.so is located in $(lldb -P)/../../../lib when creating the _lldb python symlink. Instead, use the path passed to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this variable is not set. Reviewers: vharron, emaste, zturner Subscribers: zturner, labath, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19067 llvm-svn: 267462
* Add missing qRegisterInfo option to gdbremote testcaseFrancis Ricci2016-04-251-0/+1
| | | | | | | | | | | | | | Summary: "gcc" is equivalent to "ehframe" in ProcessGDBRemote, but only "ehframe" was a valid response in the test suite. Reviewers: tfiala, jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18807 llvm-svn: 267459
* test commitFrancis Ricci2016-04-251-1/+1
| | | | llvm-svn: 267443
* Fix ARM attribute parsing for Android after rL267291Tamas Berghammer2016-04-252-14/+26
| | | | | | Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
* skip TestBitfields.py on OS XTodd Fiala2016-04-251-0/+1
| | | | | | | tracked by: https://llvm.org/bugs/show_bug.cgi?id=27515 llvm-svn: 267421
* Skip TestBitfileds on linuxPavel Labath2016-04-251-0/+1
| | | | | | | Test added in r267248 exposed a bug in handling of dwarf produced by clang>=3.9, which causes a crash during expression evaluation. Skip the test until this is sorted out. llvm-svn: 267407
* 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
* Remove flaky decorator from two tests on linuxPavel Labath2016-04-252-4/+0
| | | | | | The flakyness is no longer reproducible, and the tests seem to be passing reliably now. llvm-svn: 267392
* Add a --element-count option to the expression commandEnrico Granata2016-04-2514-13/+294
| | | | | | | | | | | | | 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-223-3/+25
| | | | | | | | 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
* Fix a build-llvm.py crasher when we can't find cmake. Now it exits with a ↵Greg Clayton2016-04-221-1/+1
| | | | | | valid error that explains what went wrong. llvm-svn: 267235
OpenPOWER on IntegriCloud