summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix the "Release" build on MacOSX for debugserver. Extra bad include paths ↵Greg Clayton2016-06-211-1/+0
| | | | | | were making things not build due to header file issues with stdio.h. llvm-svn: 273306
* Change the "debugserver-mini" target (a version of debugserverJason Molenda2016-06-213-22/+54
| | | | | | | | | | | | | | | | | | which doesn't like against all the extra UI frameworks on ios) so it now generates a binary called "debugserver-nonui" and puts it in /usr/local/bin instead of /Developer/usr/bin. Add some cruft to RNBDefs.h to get the version number (provided by Xcode at build time) with either the name "debugserver" or "debugserver_nonui" as appropriate. Add the "debugserver-mini" target to the top level "ios" target in lldb xcode project file, so this nonui debugserver will be built along with the normal lldb / debugserver. <rdar://problem/24730789> llvm-svn: 273236
* Fix typo in eOpenOptionDontFollowSymlinksFrancis Ricci2016-06-213-3/+3
| | | | | | | | | | | | Summary: Fix capitalization Reviewers: labath, sas, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D21422 llvm-svn: 273225
* Test that lldb calls the right 'printf' even when a 'printf' method exists.Sean Callanan2016-06-202-0/+25
| | | | | | This test is currently failing. We have a bug for it, as noted. llvm-svn: 273211
* Allow installing watchpoints at less than 8-byte alligned addresses for ↵Omair Javaid2016-06-166-4/+232
| | | | | | | | | | | | AArch64 targets This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses. This patch also adds tests to verify this functionality. Differential revision: http://reviews.llvm.org/D21280 llvm-svn: 272916
* xfail TestWithModuleDebugging.py on macOSTodd Fiala2016-06-161-0/+1
| | | | | | | Tracked by: https://llvm.org/bugs/show_bug.cgi?id=28156 llvm-svn: 272902
* Set TERM env var for Xcode gtestsTodd Fiala2016-06-151-1/+1
| | | | | | | | | | | | Not sure what changed, but something outside our code is failing one of the EditLine gtests on OS X CI (and locally) before the gtest ever gets to run. This fails the first EditLine gtest. This change exports the TERM as "vt100" before running the lldb-gtest binary, fixing the issue. llvm-svn: 272844
* Allow runtimes to execute custom LLVM ModulePasses over the expression IRLuke Drummond2016-06-153-1/+58
| | | | | | | | | | | | | | | | During expression evaluation, the ClangExpressionParser preforms a number of hard-coded fixups on the expression's IR before the module is assembled and dispatched to be run in a ThreadPlan. This patch allows the runtimes to register LLVM passes to be run over the generated IR, that they may perform language or architecture-specfic fixups or analyses over the generated expression. This makes expression evaluation for plugins more flexible and allows language-specific fixes to reside in their own module, rather than littering the expression evaluator itself with language-specific fixes. llvm-svn: 272800
* Add results.xml for macOS lldb unittestsTim Hammerquist2016-06-151-1/+1
| | | | | | | | | | | | | http://reviews.llvm.org/D21211 If gtest tests of lldb fail, there are no test results for Jenkins to consume. This will make the results of the gtest failure available to Jenkins. This is to address the failure visible in: http://lab.llvm.org:8080/green/job/lldb_build_test/19196/ llvm-svn: 272751
* Remove Platform usages from NativeProcessLinuxPavel Labath2016-06-142-145/+33
| | | | | | | | | | | | | | | | Summary: This removes the last usage of the Platform plugin in NPL. It was being used for determining the architecture of the debugged process. I replace the call that went through the Platform plugin with a lower level call on the ObjectFile directly. Reviewers: tberghammer Subscribers: uweigand, nitesh.jain, omjavaid, lldb-commits Differential Revision: http://reviews.llvm.org/D21324 llvm-svn: 272686
* [lldb] Fixed race conditions on private state thread exitCameron Desrochers2016-06-142-28/+34
| | | | | | | | | | This patch fixes various races between the time the private state thread is signaled to exit and the time it actually exits (during which it no longer responds to events). Previously, this was consistently causing 2-second timeout delays on process detach/stop for us. This also prevents crashes that were caused by the thread controlling its own owning pointer while the controller was using it (copying the thread wrapper is not enough to mitigate this, since the internal thread object was getting reset anyway). Again, we were seeing this consistently. Differential Revision: http://reviews.llvm.org/D21296 llvm-svn: 272682
* Add support to PlatformRemoteiOS, PlatformRemoteAppleWatch, andJason Molenda2016-06-143-0/+210
| | | | | | | | | | | | | | | | | | | | PlatformRemoteAppleTV to check the target.exec-search-paths directories for files after looking in the SDK. An additional wrinkle is that the remote file path may be something like ".../UIFoundation.framework/UIFoundation" and in target.exec-search-paths we will have "UIFoundation.framework". Looking for just the filename of the path is not sufficient - we need to also look for it by the parent directories because this may be a darwin bundle/framework like the UIFoundation example. We really need to make a PlatformRemoteAppleDevice and have PlatformRemoteiOS, PlatformRemoteAppleWatch, and PlatformRemoteAppleTV inherit from it. These three classes are 98% identical code. <rdar://problem/25976619> llvm-svn: 272635
* Add missing #include for linux.Greg Clayton2016-06-101-0/+1
| | | | | | <rdar://problem/25501013> llvm-svn: 272445
* On MacOSX, the threads can appear out of order at times depending on the ↵Greg Clayton2016-06-103-2/+24
| | | | | | | | order in which the kernel returns thread IDs to debugserver. To avoid thread lists changing order between stops, ProcessGDBRemote now makes sure the thread list stays sorted by thread index ID. <rdar://problem/25501013> llvm-svn: 272444
* Fixed C++ template integer parameter types to work correctly when the ↵Greg Clayton2016-06-104-1/+95
| | | | | | | | | | | | integer type is signed. Prior to this we would display the typename for "TestObj<-1>" as "TestObj<4294967295>" when we showed the type. Expression parsing could also fail because we would fail to find the mangled name when evaluating expressions. The issue was we were losing the signed'ness of the template integer parameter in DWARFASTParserClang.cpp. <rdar://problem/25577041> llvm-svn: 272434
* Fixed a few places that were building a regex from an identifier without ↵Greg Clayton2016-06-102-2/+2
| | | | | | | | escaping the identifier text. <rdar://problem/26090553> llvm-svn: 272423
* SBThread also had some places where it got the ExecutionContext w/o Jim Ingham2016-06-101-9/+27
| | | | | | taking the API lock. llvm-svn: 272407
* Make all the SBFrame API's take the target lock.Jim Ingham2016-06-101-14/+43
| | | | | | | | | | For some reason, the conversion to taking the target lock when acquiring the ExecutionContext was only done for some of the functions here. That was allowing lock inversion in some complex uses. <rdar://problem/26705635> llvm-svn: 272354
* Fix "frame variable" to show all variables defined in functions and any ↵Greg Clayton2016-06-091-5/+6
| | | | | | | | | | | | | | | | | | | | contained lexical blocks, even if they are static variables. For code like: int g_global = 234; int g_static = 345; int main(int argc, char **argv) { int a = 22333; static int g_int = 123; return g_global + g_static + g_int + a; } If we stop at the "return" statement, we expect to see "argc", "argv", "a" and "g_int" when we type "frame variable" since "g_int" is a locally defined static variable, but we don't expect to see "g_global" or "g_static" unless we add the -g option to "frame variable". llvm-svn: 272348
* Enable some tests on linuxPavel Labath2016-06-097-9/+5
| | | | | | | | | This enables a couple of tests which have been shown to run reliably on the linux x86 buildbot. If you see a failure after this commit, feel free to add the xfail back, but please make it as specific as possible (i.e., try to make it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9). llvm-svn: 272326
* Fixed an issue in the ProcessMachCore where segments are not always ↵Greg Clayton2016-06-091-13/+42
| | | | | | | | | | | | | | | | | | | | | | contiguous in mach-o core files. We have core files that have segments like: Address Size File off File size ---------- ---------- ---------- ---------- LC_SEGMENT 0x000f6000 0x00001000 0x1d509ee8 0x00001000 --- --- 0 0x00000000 __TEXT LC_SEGMENT 0x0f600000 0x00100000 0x1d50aee8 0x00100000 --- --- 0 0x00000000 __TEXT LC_SEGMENT 0x000f7000 0x00001000 0x1d60aee8 0x00001000 --- --- 0 0x00000000 __TEXT Any if the user executes the following command: (lldb) mem read 0xf6ff0 We would attempt to read 32 bytes from 0xf6ff0 but would only get 16 unless we loop through consecutive memory ranges that are contiguous in the address space, but not in the file data. This fixes the ProcessMachCore::DoReadMemory() to do the right thing. <rdar://problem/19729287> llvm-svn: 272322
* Fixed a problem in IRMemoryMap where the flag to zero out memory was ignored.Sean Callanan2016-06-091-0/+7
| | | | llvm-svn: 272320
* Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe.Sean Callanan2016-06-092-9/+110
| | | | | | | | | | | | | | | | | | | | | | | Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
* Fix a no newline at end of file warning.Greg Clayton2016-06-091-1/+1
| | | | llvm-svn: 272284
* Some core files on MacOSX don't have permissions setup correctly on the ↵Greg Clayton2016-06-091-1/+8
| | | | | | | | LC_SEGMENT load commands. Assume read + execute if the permissions are not set. <rdar://problem/26720522> llvm-svn: 272281
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-0911-92/+385
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* Add a test for the failure described by pr28055. Mark it as xfail.Jim Ingham2016-06-082-0/+68
| | | | llvm-svn: 272189
* Revive the error message from "process load" and SBProcess::LoadImage.Jim Ingham2016-06-081-1/+1
| | | | | | | | | | | IsPointedCString has problems with ValueObjects of type eTypeHostAddress. We should figure out the right thing to do in that case, but the test is silly here because we're reading a type we've defined, so we know it is a const char *, and if the memory is good, we won't be able to read any characters, when we do ReadPointedString. <rdar://problem/26612812> llvm-svn: 272087
* Now that there are no cycles that cause leaks in the ↵Greg Clayton2016-06-076-63/+9
| | | | | | | | disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
* Fix a memory leak in InstructionLLVMC where it held onto a strong reference ↵Greg Clayton2016-06-074-300/+394
| | | | | | | | | | | | | | | | | | | | | to the DisassemblerLLVMC which in turn had a vector of InstructionSP causing the strong cycle. This is fixed now. Rules are as follows for internal code using lldb::DisassemblerSP and lldb::InstructionSP: 1 - The disassembler needs to stay around as long as instructions do as the Instruction subclass now has a weak pointer to the disassembler 2 - The public API has been fixed so that if you get a SBInstruction, it will hold onto a strong reference to the disassembler in a new InstructionImpl class This will keep code like like: inst = lldb.target.ReadInstructions(frame.GetPCAddress(), 1).GetInstructionAtIndex(0) inst.GetMnemonic() Working as expected (not the SBInstructionList() that was returned by SBTarget.ReadInstructions() is gone, but "inst" has a strong reference inside of it to the disassembler and the instruction. All code inside the LLDB shared library was verified to correctly hold onto the disassembler instance in all places. <rdar://problem/24585496> llvm-svn: 272069
* Revert "Make lldbinline.py regenerate the Makefile each time it builds."Pavel Labath2016-06-0710-91/+17
| | | | | | This reverts commit r272024 as it is not windows-compatible. llvm-svn: 272062
* Don't use SO_REUSEADDR for *client* socketsPavel Labath2016-06-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the case of client sockets, we are not binding to a specific port, so we should be able to just request a new one. Disregarding refactors, this code has been here since the initial LLDB checkin, so I was unable to figure out whether it was added as a fix for a specific problem, or just for symmetry with server sockets, but I see no side-effect from removing it now. I was still able to create 10000 connections within a couple of seconds, so I think it's unlikely we will exhaust the port space (previously, I would get an error after a couple thousand connections). This fixes an occasional issue with connecting to the android debug bridge deamon on OSX when running the test suite, which would occasionaly fail with EADDRINUSE. My best guess is that this was happening because two processes were assigned the same client port number, and then things blew up because they were both trying to connect to the same ADB server port. I have not observed this issue happening on Linux or Windows. Reviewers: clayborg Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: http://reviews.llvm.org/D21088 llvm-svn: 272041
* LLDB is leaking memory in Editline.cpp on MacOSX. Greg Clayton2016-06-071-43/+62
| | | | | | | | | | | | When USE_SETUPTERM_WORKAROUND is enabled, we were calling setupterm() multiple times and leaking memory on each subsequent call. This is now fixed by calling setupterm() once in the constructor and tracking if we have already setup a terminal for a file descriptor. Calls to "el_set (m_editline, EL_ADDFN, ..." were leaking memory. If we switch over to call el_wset with wide strings when LLDB_EDITLINE_USE_WCHAR is set, then we no longer leak memory each time we construct a new Editline object. The calls to "el_set (m_editline, EL_ADDFN, ..." were changed over to call "el_wset (m_editline, EL_ADDFN, ...". Note that when LLDB_EDITLINE_USE_WCHAR is not defined, then el_wset is #define'ed to el_set. All strings are wrapped in EditLineConstString which will use wide strings when needed, and normal C strings when LLDB_EDITLINE_USE_WCHAR is not defined. <rdar://problem/26677627> llvm-svn: 272036
* Make lldbinline.py regenerate the Makefile each time it builds.Sean Callanan2016-06-0710-17/+91
| | | | | | | | | | | | | If a lldbinline test's source file changed language, then the Makefile wasn't updated. This was a problem if the Makefile was checked into the repository. Now lldbinline.py always regenerates the Makefile and asserts if the newly-generated version is not the same as the one already there. This ensures that the repository will never be out of date without a buildbot failing. http://reviews.llvm.org/D21032 llvm-svn: 272024
* Add support for using armv7 compact unwind informationJason Molenda2016-06-074-56/+324
| | | | | | | | | | | | | | | 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
* Don't remove PIE executables when using svr4 packetsFrancis Ricci2016-06-061-4/+3
| | | | | | | | | | | | | | | Summary: Because PIE executables have an e_type of llvm::ELF::ET_DYN, they are not of type eTypeExecutable, and were being removed when svr4 packets were used. Reviewers: clayborg, ADodds, tfiala, sas Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20990 llvm-svn: 271899
* (Minor tweak) Make RegisterContextWindows_x86/x64::GetRegisterInfoAtIndex Carlo Kok2016-06-062-2/+9
| | | | | | | | | | | | return NULL for an invalid register. The unwind logic asks for the "return address register" which doesn't exist on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up out of scope of the array bounds for g_register_infos and later SIGSEGVs on accessing. This now matches the other GetRegisterInfoAtIndex for other platforms. llvm-svn: 271876
* Fix function name lookup in IRExecutionEngine.cpp.Stephane Sezer2016-06-061-1/+1
| | | | | | | | | | | | | | Summary: Without this commit, when `log enable lldb expr` is enabled, the disassembly of JIT'ed code is never displayed. Reviewers: spyffe, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20312 llvm-svn: 271863
* Add armv7 compact unwind printing to the compact-unwind-dumper.c toolJason Molenda2016-06-041-0/+199
| | | | | | as a prototype for adding armv7 compact unwind reading to lldb. llvm-svn: 271774
* Fix a printf warning.Greg Clayton2016-06-031-2/+1
| | | | llvm-svn: 271716
* Add support in debug LLDB builds (if LLDB_CONFIGURATION_DEBUG is defined) ↵Greg Clayton2016-06-031-0/+40
| | | | | | | | | | where we can set an environment variable named LLDB_DWARF_DONT_COMPLETE_TYPENAMES that can contain one or more typenames separated by ';' characters. This will cause us to not complete any types whose names match and can help us to try and reproduce issues we see in bugs. So you can launch LLDB with the environment variable: % LLDB_DWARF_DONT_COMPLETE_TYPENAMES=Foo;Bar;Baz lldb llvm-svn: 271696
* Fix makefile for TestExternCSymbolsTamas Berghammer2016-06-031-1/+1
| | | | llvm-svn: 271618
* Fixed a problem where we couldn't call extern "C" functions.Sean Callanan2016-06-025-1/+79
| | | | | | | | | | | | | Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB has to fall back (if it is about to give up finding a symbol) to using the base name of the function. This fix also ensures that we search by full name rather than "auto," which could cause unrelated C++ names to be found. Finally, it adds a test case. <rdar://problem/25094302> llvm-svn: 271551
* LLDB needs to be able to handle DW_AT_GNU_dwo_name that are relative to the ↵Greg Clayton2016-06-021-0/+16
| | | | | | | | DW_AT_comp_dir when using -gmodules with DWARF in .o files on darwin. <rdar://problem/26590227> llvm-svn: 271545
* Fixed a problem where -gmodules debug info would be loaded by the DWO file ↵Greg Clayton2016-06-021-0/+6
| | | | | | | | support accidentally and cause 1000s of files to be mapped into LLDB's address space for each .o file that reference a module. <rdar://problem/26580266> -gmodules causes LLDB.framework to map hundreds of copies of the same .pcm file llvm-svn: 271543
* Fix JavaArraySyntheticFrontEnd for non-reference ValueObject.Tamas Berghammer2016-06-021-1/+1
| | | | | | | | | | | | Summary: Fix missing return after checking that m_backend is not a pointer or reference type. Reviewers: clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20875 llvm-svn: 271453
* [tsan] Prefer mangled name looking up variable declaration for racy addressDevin Coughlin2016-06-014-1/+99
| | | | | | | | | | | | | | | | For Thread Sanitizer reports, LLDB tries to find a global variable declaration corresponding to the racy address in order to provide a filename and line number. This commit changes the lookup of the variable to use the mangled name for lookup and fall back to the demangled version if unavailable. This is needed to report locations of races on Swift global variables. I've also added a test to make sure we look up C++ globals correctly. rdar://problem/26459401 Differential Revision: http://reviews.llvm.org/D20760 llvm-svn: 271433
* Add more verification on consectutive bitfields otherwise clang will assert.Greg Clayton2016-05-311-17/+35
| | | | | | | | We need to verify that consecutive bitfields have higher offsets and don't overlap. The issues was found by running a broken version of recent clangs where the bitfield offsets were being emitted incorrectly. To guard against this we now verify and toss out any invalid bitfields and print a message that indicates to file a bug against the compiler. <rdar://problem/25737621> llvm-svn: 271343
* [CMake] Update to requiring CMake 3.4.3Chris Bieneman2016-05-311-1/+1
| | | | | | | | | | | | | | Summary: This is as per the discussions on developer lists: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098780.html http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20826 llvm-svn: 271328
* Implement ProcessInfo::Dump(), log gdb-remote stub launchTodd Fiala2016-05-314-9/+42
| | | | | | | | | | | | | | | | | | This change implements dumping the executable, triple, args and environment when using ProcessInfo::Dump(). It also tweaks the way Args::Dump() works so that it prints a configurable label rather than argv[{index}]={value}. By default it behaves the same, but if the Dump() method with the additional arg is provided, it can be overridden. The environment variables dumped as part of ProcessInfo::Dump() make use of that. lldb-server has been modified to dump the gdb-remote stub's ProcessInfo before launching if the "gdb-remote process" channel is logged. llvm-svn: 271312
OpenPOWER on IntegriCloud