summaryrefslogtreecommitdiffstats
path: root/lldb/source/Host/common
Commit message (Collapse)AuthorAgeFilesLines
...
* Editing multi-line content in a terminal environment involves a lot ofKate Stone2016-07-141-37/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | trade-offs. When LLDB's multi-line editing support was first introduced for expressions / REPL contexts the behavior was as follows: * The Return key is treated as a line-break except at the end of the input buffer, where a completeness test is applied This worked well enough when writing code, and makes it trivial to insert new lines above code you've already typed. Just use cursor navigation to move up and type freely. Where it was awkward is that the gesture to insert a line break and end editing is conflated for most people. Sometimes you want Return to end the editing session and other times you want to insert a line break. This commit changes the behavior as follows: * The Return key is treated as the end of editing except at the end of the input buffer, where a completeness test is applied * The Meta+Return sequence is always treated as a line break. This is consistent with conventions in Facebook and elsewhere since Alt/Option+Return is often mapped to Meta+Return. The unfortunate exception is on macOS where this *can* be the case, but isn't by default. Sigh. Note that by design both before and after the patch pasting a Return character always introduces a line break. <rdar://problem/26886287> llvm-svn: 275482
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-231-1/+1
| | | | | | | | for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll need to look at this more closely before re-committing. (passed OK on macOS ;) llvm-svn: 273531
* Do some minor renames of "Mac OS X" to "macOS".Jason Molenda2016-06-231-1/+1
| | | | | | | | | There's uses of "macosx" that will be more tricky to change, like in triples (e.g. "x86_64-apple-macosx10.11") - for now I'm just updating source comments and strings printed for humans. llvm-svn: 273524
* Fix typo in eOpenOptionDontFollowSymlinksFrancis Ricci2016-06-211-1/+1
| | | | | | | | | | | | Summary: Fix capitalization Reviewers: labath, sas, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D21422 llvm-svn: 273225
* 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
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-3/+3
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-184-48/+45
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Generalize child process monitoring functionsPavel Labath2016-05-113-48/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the C-style "void *" baton of the child process monitoring functions with a more C++-like API taking a std::function. The motivation for this was that it was very difficult to handle the ownership of the object passed into the callback function -- each caller ended up implementing his own way of doing it, some doing it better than others. With the new API, one can just pass a smart pointer into the callback and all of the lifetime management will be handled automatically. This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate commit to reduce the scope of this change. Reviewers: clayborg, zturner, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20106 llvm-svn: 269205
* Revert "Add a read_full_buffer argument to ConnectionFileDescriptor::Read"Pavel Labath2016-05-031-3/+2
| | | | | | | This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to ConnectionGenericFileWindows). llvm-svn: 268384
* Add a read_full_buffer argument to ConnectionFileDescriptor::ReadPavel Labath2016-05-031-2/+3
| | | | | | | | | | | | | | | | | | | | | Summary: AdbClient was attempting to handle the case where the socket input arrived in pieces, but it was failing to handle the case where the connection was closed before that happened. In this case, it would just spin in an infinite loop calling Connection::Read. (This was also the cause of the spurious timeouts on the darwin->android buildbot. The exact cause of the premature EOF remains to be investigated, but is likely a server bug.) Since this wait-for-a-certain-number-of-bytes seems like a useful functionality to have, I am moving it (with the infinite loop fixed) to the Connection class, and adding an appropriate test for it. Reviewers: clayborg, zturner, ovyalov Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: http://reviews.llvm.org/D19533 llvm-svn: 268380
* 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
* Support Linux on SystemZ as platformUlrich Weigand2016-04-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
* FileSpec: make matching separator-agnostic againPavel Labath2016-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a problem because we would consider paths with different separators as different (which led to unresolved breakpoints for instance). Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I am commenting out the GetDirectory unittests until we figure out the what is the expected behaviour here. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19060 llvm-svn: 266286
* Make FileSpec handling platform-independentPavel Labath2016-04-041-26/+100
| | | | | | | | | | | | | | | | | 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
* Unicode support on Win32.Zachary Turner2016-03-222-24/+49
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Remove unnecessary <limits> includes.Jim Ingham2016-03-151-2/+4
| | | | llvm-svn: 263588
* Fix a couple of cornercases in FileSpec + testsPavel Labath2016-03-111-24/+22
| | | | | | | | | | | | | | | | | | | Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
* Fixed the python interpreter so that it correctly inherits the top ↵Greg Clayton2016-03-101-51/+0
| | | | | | | | | | IOHandler's files instead of always using stdin/out/err. Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn. <rdar://problem/24877720> llvm-svn: 263161
* Add support for reading line tables from PDB files.Zachary Turner2016-03-021-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | PDB is Microsoft's debug information format, and although we cannot yet generate it, we still must be able to consume it. Reason for this is that debug information for system libraries (e.g. kernel32, C Runtime Library, etc) only have debug info in PDB format, so in order to be able to support debugging of system code, we must support it. Currently this code should compile on every platform, but on non-Windows platforms the PDB plugin will return 0 capabilities, meaning that for now PDB is only supported on Windows. This may change in the future, but the API is designed in such a way that this will require few (if any) changes on the LLDB side. In the future we can just flip a switch and everything will work. This patch only adds support for line tables. It does not return information about functions, types, global variables, or anything else. This functionality will be added in a followup patch. Differential Revision: http://reviews.llvm.org/D17363 Reviewed by: Greg Clayton llvm-svn: 262528
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-4/+2
| | | | | | the right thing and break. llvm-svn: 261950
* Some fixes for case insensitive paths on Windows.Zachary Turner2016-02-241-53/+61
| | | | | | | | | | | | | | | | | | | Paths on Windows are not case-sensitive. Because of this, if a file is called main.cpp, you should be able to set a breakpoint on it by using the name Main.cpp. In an ideal world, you could just tell people to match the case, but in practice this can be a real problem as it requires you to know whether the person who compiled the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of which would work, regardless of what the file was actually called. This fixes http://llvm.org/pr22667 Patch by Petr Hons Differential Revision: http://reviews.llvm.org/D17492 Reviewed by: zturner llvm-svn: 261771
* Don't use an atexit handler for cleaning up the temp directory.Zachary Turner2016-02-191-16/+17
| | | | | | Differential Revision: http://reviews.llvm.org/D17420 llvm-svn: 261353
* Fix an off-by-one in SocketTest::DecodeHostAndPortPavel Labath2016-02-031-1/+1
| | | | | | | 65535 is still a valid port. This should fix the android failures we were getting when we chose to connect over 65535 to the remote lldb-server. llvm-svn: 259638
* We try to avoid static objects. These are on the error path for unsupported ↵Jim Ingham2016-02-021-4/+4
| | | | | | | | features in the socket, so just returning freshly constructed objects is fine. llvm-svn: 259443
* Fix a problem where we were not calling fcntl() with the correct arguments ↵Enrico Granata2016-01-201-2/+2
| | | | | | | | | | | for F_DUPFD On Mac OS X, this was working just fine in debug builds (presumably, because the right value ended up being at the right location for the variadic ABI), but not in Release builds As a result, we were seeing failures with commands that set their own immediate output stream - only in Release builds, which always makes for a fun little investigation I have removed those fcntl() calls and replaced them with dup() calls. This fixes the issue in both Debug and Release builds llvm-svn: 258367
* Fix an issue where scripted commands would not actually print any of their ↵Enrico Granata2016-01-131-0/+9
| | | | | | | | output if an immediate output file was set in the result object via a Python file object Fixes rdar://24130303 llvm-svn: 257644
* Make the aarch64 lldb-server capable of debugging arm32 applicationsTamas Berghammer2016-01-111-1/+1
| | | | | | Differential revision: http://reviews.llvm.org/D15533 llvm-svn: 257322
* [Editline] Redesign automatic indentation fix command for robustnessKate Stone2015-12-141-20/+33
| | | | | | The FixIndentationCommand implementation has proven to be fragile across various libedit iterations. This patch reworks the command to use the same basic strategy as when moving between lines in a multi-line edit session: when indentation changes are required, exit line editing completely and restart with amended content. This approach won't be susceptible to subtle behavior differences libedit has introduced over time. llvm-svn: 255548
* Fix pessimizing moves. Found by clang.Davide Italiano2015-11-071-1/+1
| | | | llvm-svn: 252409
* LLDB needs a mutex around getopt_long_only() function calls to avoid ↵Jim Ingham2015-11-051-1/+3
| | | | | | | | multi-threading option parsing issues. <rdar://problem/17052381> llvm-svn: 252111
* Fix editline unindentation code for more recent libedits.Todd Fiala2015-10-271-2/+5
| | | | | | | | This code was modifying the cursor and then expecting the editline API call to see the effect for the next operation. This is misusing the API. Newer editlines break on this code, fixed by this. llvm-svn: 251457
* Use accept4 workaround for MIPS Android build.Chaoren Lin2015-10-271-3/+3
| | | | | | | | | | | | Summary: Similar to http://reviews.llvm.org/rL242319, which was for ARM. Reviewers: chying, ovyalov Subscribers: aemerson, tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D14127 llvm-svn: 251439
* Add Socket::Create factory method which uses socket protocol to find an ↵Oleksiy Vyalov2015-10-271-21/+41
| | | | | | | | appropriate implementation class. http://reviews.llvm.org/D14085 llvm-svn: 251417
* Add support for abstract domain sockets.Oleksiy Vyalov2015-10-221-0/+42
| | | | | | http://reviews.llvm.org/D13970 llvm-svn: 251034
* When calling FileSpec::AppendPathComponent() we don't need to include "." in ↵Greg Clayton2015-10-201-1/+1
| | | | | | | | | | | | | | | | | | | the path if m_filename is set to exactly '.'. Previously this would cause a FileSpec object that looked like: m_directory = "/tmp" m_filename = "." To look like: m_directory = "/tmp/." m_filename = "foo.txt" if "foo.txt" was appended to it. With this fix it will be: m_directory = "/tmp" m_filename = "foo.txt" llvm-svn: 250770
* Added the concept of a Read-Eval-Print-Loop to LLDB.Sean Callanan2015-10-191-0/+14
| | | | | | | | | | | | | | | | A REPL takes over the command line and typically treats input as source code. REPLs can also do code completion. The REPL class allows its subclasses to implement the language-specific functionality without having to know about the IOHandler-specific internals. Also added a PluginManager-based way of getting to a REPL given a language and a target. Also brought in some utility code and expression options that are useful for REPLs, such as line offsets for expressions, ANSI terminal coloring of errors, and a few IOHandler convenience functions. llvm-svn: 250753
* Silence -Wqual-cast warnings from GCC 5.2Saleem Abdulrasool2015-10-181-3/+3
| | | | | | | | There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
* Fix temporary directory computation on linux (pr25147)Pavel Labath2015-10-161-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: On linux, the environment variables for temp directories that lldb checks for are generally not defined, and the temp directory computation failed. This caused expression evaluation to fall back to creating "/tmp/lldb-*.expr" debugging files instead of the usual "$TMP/lldb/pid/lldb-*.expr". Crucially, these files were not cleaned up on lldb exit, which caused clutter in the /tmp folder, especially on long-running machines (e.g. builtbots). This commit fixes lldb to use llvm::sys::path::system_temp_directory, which does the same environment variable dance, but (!) also falls back to the P_tmpdir macro, which is how the temp directory is defined on linux. Since the linux temp path computation now succeeds, I needed to also modify Android path computation to check for actual directory existence, rather then checking whether the operation failed. Reviewers: clayborg, tberghammer Subscribers: tberghammer, lldb-commits, danalbert, srhines, emaste Differential Revision: http://reviews.llvm.org/D13772 llvm-svn: 250502
* Split Socket class into Tcp/Udp/DomainSocket subclasses.Oleksiy Vyalov2015-10-153-469/+546
| | | | | | http://reviews.llvm.org/D13754 llvm-svn: 250474
* Introduce a `PythonFile` object, and use it everywhere.Zachary Turner2015-10-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | Python file handling got an overhaul in Python 3, and it affects the way we have to interact with files. Notably: 1) `PyFile_FromFile` no longer exists, and instead we have to use `PyFile_FromFd`. This means having a way to get an fd from a FILE*. For this we reuse the lldb_private::File class to convert between FILE*s and fds, since there are some subtleties regarding ownership rules when FILE*s and fds refer to the same file. 2) PyFile is no longer a builtin type, so there is no such thing as `PyFile_Check`. Instead, files in Python 3 are just instances of `io.IOBase`. So the logic for checking if something is a file in Python 3 is to check if it is a subclass of that module. Additionally, some unit tests are added to verify that `PythonFile` works as expected on Python 2 and Python 3, and `ScriptInterpreterPython` is updated to use `PythonFile` instead of manual calls to the various `PyFile_XXX` methods. llvm-svn: 250444
* Revert "Fix temporary directory computation on linux (pr25147)"Pavel Labath2015-10-151-4/+13
| | | | | | I actually did not want to commit this without review, but I mistyped. :/ llvm-svn: 250412
* Fix temporary directory computation on linux (pr25147)Pavel Labath2015-10-151-13/+4
| | | | | | | | | | | | | | | | | On linux, the environment variables for temp directories that lldb checks for are generally not defined, and the temp directory computation failed. This caused expression evaluation to fall back to creating "/tmp/lldb-*.expr" debugging files instead of the usual "$TMP/lldb/pid/lldb-*.expr". Crucially, these files were not cleaned up on lldb exit, which caused clutter in the /tmp folder, especially on long-running machines (e.g. builtbots). This commit fixes lldb to use llvm::sys::path::system_temp_directory, which does the same environment variable dance, but (!) also falls back to the P_tmpdir macro, which is how the temp directory is defined on linux. Since the linux temp path computation now succeeds, I needed to also modify Android path computation to check for actual directory existence, rather then checking whether the operation failed. llvm-svn: 250409
* Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in ↵Vadim Macagon2015-10-131-0/+2
| | | | | | | | | | | | | | | | /usr/lib/debug on Windows Summary: /usr/lib/debug doesn't exist on Windows so there's no point even attempting to look for symbol files in there. Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13636 llvm-svn: 250175
* Re-commit the (fixed) changes from r248985 which were reverted by PavelJason Molenda2015-10-081-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
* Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()Bruce Mitchener2015-10-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `module_spec.GetFileSpec().GetDirectory().AsCString()` returned a `nullptr` this line caused a segmentation fault: `std::string module_directory = module_spec.GetFileSpec().GetDirectory().AsCString()` Some context: I was remote debugging an executable built with Clang in an Ubuntu VM on my Windows machine using lldb-mi. I copied the executable and nothing else from the Ubuntu VM to the Windows machine. Then started lldb-server in the Ubuntu VM: ``` ./bin/lldb-server gdbserver *:8888 -- /home/enlight/Projects/dbgmits/build/Debug/data_tests_target ``` And ran `lldb-mi --interpreter` on Windows with the following commands: ``` -file-exec-and-symbols C:\Projects\data_tests_target -target-select remote 192.168.56.101:8888 -exec-continue ``` After which the segmentation fault occurred at the aforementioned line. Inside this method `module_spec.GetFileSpec()` returns an empty `FileSpec` (no dir, no filename), while `module_spec.GetSymbolFileSpec().GetFilename()` returns `"libc-2.19.so"`. Patch thanks to Vadim Macagon. Reviewers: brucem, zturner, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13201 llvm-svn: 249387
* Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..."Pavel Labath2015-10-011-14/+11
| | | | | | | This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
* Fixing a subtle issue on Mac OS X systems with dSYMs (possiblyJason Molenda2015-10-011-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 248985
* Moved ResolveSymbolicLink() to the FileSystem where it belongs, thanksSean Callanan2015-09-182-27/+1
| | | | | | | | zturner! http://reviews.llvm.org/D12984 llvm-svn: 248055
* Added support for resolving symbolic links to FileSpec.Sean Callanan2015-09-182-1/+30
| | | | | | | | | | | | | | | We use the symbolic link to resolver to find the target of the LLDB shlib symlink if there is a symlink. This allows us to find shlib-relative resources even when running under the testsuite, where _lldb.so is a symlink in the Python resource directory. Also changed a comment to be slightly more clear about what resolve_path in the constructor for FileSpec means, since if we were actually using realpath() this code wouldn't have been necessary. http://reviews.llvm.org/D12984 llvm-svn: 248048
OpenPOWER on IntegriCloud