summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
* Revert "XFail TestImport.py on Windows because Python 3 import rules don't ↵Adrian McCarthy2016-04-051-1/+0
| | | | | | | | work that way." This reverts commit e5f0ba4fcf977ad6baaaca700d3646675cdac19b. llvm-svn: 265476
* XFail TestImport.py on Windows because Python 3 import rules don't work that ↵Adrian McCarthy2016-04-051-0/+1
| | | | | | way. llvm-svn: 265461
* Fix a crasher that could happen if ClangASTSource::CompleteType() found a ↵Greg Clayton2016-04-051-3/+3
| | | | | | | | type whose name matched, but came from a different language. We need to verify that any types we find are clang types before trying to extra a clang::QualType and then use it. <rdar://problem/24138711> llvm-svn: 265443
* Fix dotest.py '-p' option for multi-process modeStephane Sezer2016-04-051-0/+4
| | | | | | | | | | | | | | | | | Summary: The '-p' option for dotest.py was ignored in multiprocess mode, as the -p argument to the inferior would overwrite the -p argument passed on the command line. Reviewers: zturner, tfiala Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18779 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265422
* Update watchpoint help to use new -s flagStephane Sezer2016-04-051-7/+7
| | | | | | | | | | | | | | Summary: Flag updated in D233237 Reviewers: spyffe, jingham, Eugene.Zelenko Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18660 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265421
* Print environment when dumping arch tripleStephane Sezer2016-04-051-0/+4
| | | | | | | | | | | | | | Summary: Print environment from triple if it exists. Reviewers: tfiala, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18620 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265420
* Make sure to update Target arch if environment changedStephane Sezer2016-04-051-1/+1
| | | | | | | | | | | | | | Summary: Fixes "target list" for non-android linux platforms (ie gnu, gnueabi) Reviewers: jasonmolenda, tfiala, clayborg, tberghammer Subscribers: tberghammer, danalbert, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18631 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265419
* Allow gdbremote process to read modules from memoryStephane Sezer2016-04-055-63/+22
| | | | | | | | | | | | | | | | | | | | | | Summary: The logic to read modules from memory was added to LoadModuleAtAddress in the dynamic loader, but not in process gdb remote. This means that when the remote uses svr4 packets to give library info, libraries only present on the remote will not be loaded. This patch therefore involves some code duplication from LoadModuleAtAddress in the dynamic loader, but removing this would require some amount of code refactoring. Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted Subscribers: tfiala, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18531 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265418
* Reverting r265401 ("Enabling AddressSanitizer tests, they should work now.")Kuba Brecka2016-04-052-0/+2
| | | | llvm-svn: 265406
* Enabling AddressSanitizer tests, they should work now.Kuba Brecka2016-04-052-2/+0
| | | | llvm-svn: 265401
* Fixing AddressSanitizer tests (update expectations for current ASan, make it ↵Kuba Brecka2016-04-052-23/+13
| | | | | | work on OS X 10.10 and older). llvm-svn: 265400
* [NFC] Cleanup the code used to run shell commands from testsTamas Berghammer2016-04-056-71/+34
| | | | | | | | | | | | Previously we had 3 different method to run shell commands on the target and 4 copy of code waiting until a given file appears on the target device (used for syncronization). This CL merges these methods to 1 run_platform_command and 1 wait_for_file_on_target functions located in some utility classes. Differential revision: http://reviews.llvm.org/D18789 llvm-svn: 265398
* Enabling TSan tests, they should work now.Kuba Brecka2016-04-052-2/+0
| | | | llvm-svn: 265396
* Fix ThreadSanitizer test cases to work on OS X 10.10 and older.Kuba Brecka2016-04-052-0/+10
| | | | llvm-svn: 265395
* Fix TestPlatformProcessConnect after rL265357Tamas Berghammer2016-04-051-1/+5
| | | | llvm-svn: 265392
* Fix a bug in linux core file handlingPavel Labath2016-04-0510-10/+106
| | | | | | | | | | | | | | | | | | | Summary: There was a bug in linux core file handling, where if there was a running process with the same process id as the id in the core file, the core file debugging would fail, as we would pull some pieces of information (ProcessInfo structure) from the running process instead of the core file. I fix this by routing the ProcessInfo requests through the Process class and overriding it in ProcessElfCore to return correct data. A (slightly convoluted) test is included. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18697 llvm-svn: 265391
* Consolidate the knowledge of what arm cores are always executingJason Molenda2016-04-055-26/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in thumb mode into one method in ArchSpec, replace checks for specific cores in the disassembler with calls to this. Also call this from the arm instruction emulation code. The determination of whether a given ArchSpec is thumb-only is still a bit of a hack, but at least the hack is consolidated into a single place. In my original version of this patch http://reviews.llvm.org/D13578 I was calling into llvm's feature arm feature tables to make this determination, like #include "llvm/Support/TargetRegistry.h" #include "llvm/MC/MCSubtargetInfo.h" #include "llvm/../../lib/Target/ARM/ARMGenRegisterInfo.inc" #include "llvm/../../lib/Target/ARM/ARMFeatures.h" [...] std::string triple (GetTriple().getTriple()); const char *cpu = ""; const char *features_str = ""; const llvm::Target *curr_target = llvm::TargetRegistry::lookupTarget(triple.c_str(), Error); std::unique_ptr<llvm::MCSubtargetInfo> subtarget_info_up (curr_target->createMCSubtargetInfo(triple.c_str(), cpu, features_str)); if (subtarget_info_up->getFeatureBits()[llvm::ARM::FeatureNoARM]) { return true; } but those tables are post-llvm-build generated and linking against them for all of our different build system methods was a big hiccup that I haven't had time to revisit convincingly. I'll keep that reviews.llvm.org patch around to remind myself that I need to take another run at linking against the necessary tables again in llvm. <rdar://problem/23022803> llvm-svn: 265377
* Improve the way LLDB escapes arguments before passing them to the shellEnrico Granata2016-04-046-7/+45
| | | | | | | | | | | | | Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch) This makes those launch scenarios work transparently via shell expansion Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly Fixes rdar://problem/22749408 llvm-svn: 265357
* Implement `target modules dump objfile`Adrian McCarthy2016-04-042-6/+122
| | | | | | Differential Revision: http://reviews.llvm.org/D18464 llvm-svn: 265349
* disabled TSAN tests until the author can help track down CI failuresTodd Fiala2016-04-042-0/+2
| | | | | | | These tests run fine locally for me but are failing on the Green Dragon OS X CI. llvm-svn: 265342
* Xcode: run gtests when building the lldb-gtest targetTodd Fiala2016-04-041-0/+15
| | | | | | | This addresses the following task: https://llvm.org/bugs/show_bug.cgi?id=27181 Xcode gtests: ensure they run, not just build, on Xcode target llvm-svn: 265340
* Xcode: modify lldb-python-test-suite target to build inferiors with ↵Todd Fiala2016-04-041-1/+5
| | | | | | | | | | $(LLDB_PYTHON_TESTSUITE_CC) $(LLDB_PYTHON_TESTSUITE_CC) defaults to the just-built clang. Together with changes to the zorg repo, this enables the Green Dragon LLDB OS X Xcode-based builder to run the new TSAN LLDB tests. llvm-svn: 265315
* Set the architecture type from minidump more precisely. Differentiate i686 ↵Adrian McCarthy2016-04-041-2/+10
| | | | | | v i386 when possible. llvm-svn: 265308
* Make FileSpec handling platform-independentPavel Labath2016-04-042-40/+119
| | | | | | | | | | | | | | | | | Summary: Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both platforms, it relied on the llvm path library to do its work, whose behavior differed on different platforms. This led to subtle differences in FileSpec behavior between platforms. This replaces the pieces of the llvm library with our own implementations. The functions are simply copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18689 llvm-svn: 265299
* Fix flakyness in TestWatchpointMultipleThreadsPavel Labath2016-04-042-7/+2
| | | | | | | This addresses the same problem as r264846 (the test not expecting the situation when two thread hit the watchpoint simultaneously), but for a different test. llvm-svn: 265294
* Add some unit tests for ClangASTContext.Zachary Turner2016-04-016-133/+416
| | | | | | | | | | | 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
* Fixed an issue where if we have DWARF in an executable that has multiple ↵Greg Clayton2016-04-013-3/+27
| | | | | | | | | | | | | | languages where these languages use different type systems, you can end up trying to find the actualy definition for a forward declaration for a type, you will call: TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx); The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty. This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations. <rdar://problem/25276165> llvm-svn: 265196
* skip and xfail two std::list-related libcxx tests that fail on OS X with TOT ↵Todd Fiala2016-04-012-0/+2
| | | | | | | | | | | | | libcxx Enrico has a bug on him to make this work across older libcxx list and newer libcxx list simultaneously. Needed in preparation of getting the OS X public CI to run the TSAN tests. tracked by: rdar://25499635 llvm-svn: 265188
* Remove more of the code-running ObjC data formatter supportEnrico Granata2016-04-014-145/+41
| | | | llvm-svn: 265181
* mark TestCallWithTimeout.py XFAIL on macosx.Todd Fiala2016-04-011-1/+1
| | | | | | | | | | This test is failing on the CI but not locally for me. Needs investigation. tracked by: https://llvm.org/bugs/show_bug.cgi?id=27182 llvm-svn: 265175
* Guard xunit result test class and test method name access to prevent testbot ↵Todd Fiala2016-04-011-2/+2
| | | | | | | | breakage http://llvm.org/bugs/show_bug.cgi?id=27179 llvm-svn: 265165
* Fix clean rule for a makefilePavel Labath2016-04-011-1/+1
| | | | | | | The test was failing on windows because the clean rule (which is executed even if the test is skipped) returned an error there. llvm-svn: 265140
* Change a recently added assert into lldbassertPavel Labath2016-04-011-1/+2
| | | | llvm-svn: 265124
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-016-9/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling: rnb_err_t RNBRemote::HandlePacket_stop_process (const char *p) { if (!DNBProcessInterrupt(m_ctx.ProcessID())) HandlePacket_last_signal (NULL); return rnb_success; } In the call to DNBProcessInterrupt we did: nub_bool_t DNBProcessInterrupt(nub_process_t pid) { MachProcessSP procSP; if (GetProcessSP (pid, procSP)) return procSP->Interrupt(); return false; } This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response. To fix this I did the following: 1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines 2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen 3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply. 5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response. 6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() 7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process. The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (incorrect extra stop reply packet) --> c <-- OK (response from z0 packet) Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets) <-- OK -- (we are back on track as this is a valid response to z0) ... As time goes on we should add more packet validators. <rdar://problem/22859505> llvm-svn: 265086
* Don't vary debug info for lldb-server testsPavel Labath2016-03-312-1/+13
| | | | | | | | | | | | | | | | | | Summary: Debug info is used only by the client and lldb-server tests do not even have the client component running, as they communicate with the server directly. Therefore, running the tests for each debug info type is unnecessarry. This adds general ability to mark a test class as not dependent on debug info, and marks all lldb-server tests as such. Reviewers: tberghammer, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18598 llvm-svn: 265017
* Fix DWO breakage in r264909Pavel Labath2016-03-314-3/+13
| | | | | | | | | | | | | | | | | | | Summary: In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo. The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup the compilation unit in the DWO based on the main object file offset (and failed). I change the implementation to verify the DIERef indeed references compile unit belonging to this dwo and then lookup the die based on the die offset alone. Includes a couple of fixes for mismatched struct/class tags. Reviewers: tberghammer, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18646 llvm-svn: 265011
* Add --help and --long-help options to 'command alias' such that one can now ↵Enrico Granata2016-03-312-7/+168
| | | | | | specify a help string for an alias as they are defining it llvm-svn: 264980
* Enhance the 'type X list' commands such that they actually alert the user if ↵Enrico Granata2016-03-303-11/+26
| | | | | | no formatters matching the constraints could be found llvm-svn: 264957
* Fixed a problem where a dSYM wasn't properly found because it had the wrong nameSean Callanan2016-03-302-2/+3
| | | | | | <rdar://problem/25447765> llvm-svn: 264914
* When support for DWO files was added, there were two ways to pass ↵Greg Clayton2016-03-3018-333/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb::user_id_t out to the rest of LLDB: 1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset 2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset There was a mixing and matching of this and it wasn't done consistently. Major changes include: The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF: DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf) It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF. The function: lldb::user_id_t DIERef::GetUID() const; Now becomes lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const; Again, we need the DWARF file to encode it correctly. This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like: 1 - encode a dw_offset_t into a lldb::user_id_t 2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t 3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type. There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext. If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map. <rdar://problem/25200976> llvm-svn: 264909
* Fix header name.Jim Ingham2016-03-301-1/+1
| | | | llvm-svn: 264883
* Fix the ThreadSanitizer support to avoid creating empty SBThreads and to not ↵Kuba Brecka2016-03-302-2/+6
| | | | | | crash when thread_id is unavailable. Plus a whitespace fix. llvm-svn: 264854
* Fix SocketAddressTest (again)Pavel Labath2016-03-301-1/+2
| | | | | | | On some versions of Windows, the address is returned as "::1", while on others it's "0:0:...:0:1". Accept both versions, as they represent the same address. llvm-svn: 264850
* Fix warning in ThreadSanitizerRuntimePavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264849
* Fix warning in ClangExpressionParserPavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264847
* Fix flakyness in TestWatchpointMultipleThreadsPavel Labath2016-03-302-13/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: the inferior in the test deliberately does not lock a mutex when accessing the watched variable. The reason for that is unclear as, based on the logs, the original intention of the test was to check whether watchpoints get propagated to newly created threads, which should work fine even with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time to time) that two threads do manage the execute the "critical section" simultaneously, the test will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2. Given this, I have simply chose to lock the mutex always, so that we have more predictible behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by TestConcurrentEvents. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18558 llvm-svn: 264846
* Don't register the addresses of private symbols from expressions.Sean Callanan2016-03-301-1/+1
| | | | | | | | They're not supposed to go in the symbol table, and in fact the way the JIT is currently implemented it sometimes crashes when you try to get the address of such a function. So we skip them. llvm-svn: 264821
* Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out ↵Greg Clayton2016-03-303-6/+6
| | | | | | | | | | | | | | | | | | | | | that there are few things to watch out for when writing pexpect tests: 1 - If you plan on looking for the "(lldb) " prompt as a regular expression, look for "\(lldb\) " so you don't just find "lldb". 2 - Make sure to not use colors (specify --no-use-colors as an option to lldb when launching it) as our editline will print: "(lldb) <color junk>(lldb) " where "<color junk>" is a work around that is used to allow us to colorize our prompts. The bad thing is this will make pexepct code like this not execute as you would expect: prompt = "\(lldb\) " self.child.sendline("breakpoint set ...", prompt) self.child.sendline("breakpoint clear ...", prompt) The problem is the first "sendline" will create two lldb prompts and will match both the first and second prompts and you output will get off. So be sure to disable colors if you need to. Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have spaces in your directory names. I modified custom_command.py to use shlex to parse arguments and I quoted the file path we sent down to the custom_command.write_file function. llvm-svn: 264810
* LLDB top of tree SVN fails to attach to a MacOSX native process by pid only ↵Greg Clayton2016-03-291-2/+2
| | | | | | | | | | (no executable). The problem was that the static DynamicLoaderDarwinKernel::Initialize() was recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel would claim it could be the dynamic loader for a user space MacOSX process. The fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough when vetting the process so that it doesn't claim MacOSX user space processes. <rdar://problem/25425373> llvm-svn: 264794
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-2913-68/+217
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
OpenPOWER on IntegriCloud