summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Path.inc
Commit message (Collapse)AuthorAgeFilesLines
* Merging r340751:Hans Wennborg2018-08-301-2/+4
| | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r340751 | hans | 2018-08-27 17:55:39 +0200 (Mon, 27 Aug 2018) | 7 lines Use a lambda for calls to ::open in RetryAfterSignal In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing compile errors of RetryAfterSignal due to overload resolution. Wrapping the call in a lambda avoids this. Based on a patch by Chih-Wei Huang <cwhuang@linux.org.tw>! ------------------------------------------------------------------------ llvm-svn: 341044
* [Support] Build fix for Haiku when checking for a local filesystemTim Northover2018-07-181-0/+3
| | | | | | | | | Haiku does not expose information about local versus remote mounts, so just return false, like Cygwin. Patch by Niels Sascha Reedijk. llvm-svn: 337389
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
* Fix build errors on some configurationsPavel Labath2018-06-111-1/+1
| | | | | | | | | | | | It's been reported <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180611/559616.html> that template argument deduction for RetryAfterSignal fails if open is not prefixed with "::". This should help us build correctly on those platforms and explicitly specifying the namespace is more correct anyway. llvm-svn: 334403
* Cleanup. NFCFangrui Song2018-06-101-1/+1
| | | | llvm-svn: 334357
* Add a file open flag that disables O_CLOEXEC.Zachary Turner2018-06-081-4/+7
| | | | | | | | | | | O_CLOEXEC is the right default, but occasionally you don't want this. This is especially true for tools like debuggers where you might need to spawn the child process with specific files already open, but it's occasionally useful in other scenarios as well, like when you want to do some IPC between parent and child. llvm-svn: 334293
* Expose a single global file open function.Zachary Turner2018-06-071-35/+14
| | | | | | | | | This one allows much more flexibility than the standard openFileForRead / openFileForWrite functions. Since there is now just one "real" function that does the work, all other implementations simply delegate to this one. llvm-svn: 334246
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-44/+81
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [Support] Add functions that operate on native file handles on Windows.Zachary Turner2018-06-041-0/+26
| | | | | | | | | | | | | | | | | | | | Windows' CRT has a limit of 512 open file descriptors, and fds which are generated by converting a HANDLE via _get_osfhandle count towards this limit as well. Regardless, often you find yourself marshalling back and forth between native HANDLE objects and fds anyway. If we know from the getgo that we're going to need to work directly with the handle, we can cut out the marshalling layer while also not contributing to filling up the CRT's very limited handle table. On Unix these functions just delegate directly to the existing set of functions since an fd *is* the native file type. It would be nice, very long term, if we could convert most uses of fds to file_t. Differential Revision: https://reviews.llvm.org/D47688 llvm-svn: 333945
* [Support] Support building LLVM for FuchsiaPetr Hosek2018-05-031-0/+3
| | | | | | | | | | These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
* Remove HAVE_DIRENT_H.Nico Weber2018-04-021-17/+2
| | | | | | | The autoconf manual: "This macro is obsolescent, as all current systems with directory libraries have <dirent.h>. New programs need not use this macro." llvm-svn: 328989
* [Support] Add WriteThroughMemoryBuffer.Zachary Turner2018-03-081-1/+1
| | | | | | | | | | | This is like MemoryBuffer (read-only) and WritableMemoryBuffer (writable private), but where the underlying file can be modified after writing. This is useful when you want to open a file, make some targeted edits, and then write it back out. Differential Revision: https://reviews.llvm.org/D44230 llvm-svn: 327057
* Silence warning about unused private variable.Zachary Turner2018-02-151-1/+3
| | | | llvm-svn: 325275
* [Support] Use realpath(3) instead of trying to open a file.Davide Italiano2018-01-091-6/+6
| | | | | | | | | If we don't have read permissions on the directory the call would fail. <rdar://problem/35871293> llvm-svn: 322095
* [Support/UNIX] posix_fallocate() can fail with EINVAL.Davide Italiano2017-11-071-1/+1
| | | | | | | | | | | | | | | | | According to the docs on opegroup.org, the function can return EINVAL if: The len argument is less than zero, or the offset argument is less than zero, or the underlying file system does not support this operation. I'd say it's a peculiar choice (when EONOTSUPP is right there), but let's keep POSIX happy for now. This was independently discovered by Mark Millard (on FreeBSD/ZFS). Quickly ack'ed by Rui on IRC. llvm-svn: 317535
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-7/+13
| | | | | | | | | | | | | | | | | | FindFirstFileEx/FindNextFile results on Windows. This allows clients to avoid an unnecessary fs::status() call on each directory entry. Because the information returned by FindFirstFileEx is a subset of the information returned by a regular status() call, I needed to extract a base class from file_status that contains only that information. On my machine, this reduces the time required to enumerate a ThinLTO cache directory containing 520k files from almost 4 minutes to less than 2 seconds. Differential Revision: https://reviews.llvm.org/D38716 llvm-svn: 315378
* [Support] mapped_file_region::size() returns size_tRoman Lebedev2017-09-271-1/+1
| | | | | | Fixup last commit, found by clang-stage1-cmake-RA-incremental bot. llvm-svn: 314313
* [Support] mapped_file_region: store size as size_tRoman Lebedev2017-09-271-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Found when testing stage-2 build with D38101. ``` In file included from /build/llvm/lib/Support/Path.cpp:1045: /build/llvm/lib/Support/Unix/Path.inc:648:14: error: comparison 'uint64_t' (aka 'unsigned long') > 18446744073709551615 is always false [-Werror,-Wtautological-constant-compare] if (length > std::numeric_limits<size_t>::max()) { ~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` `size_t` is `uint64_t` here, apparently, thus any `uint64_t` value always fits into `size_t`. Initial patch was to use some preprocessor logic to not check if the size is known to fit at compile time. But Zachary Turner suggested using this approach. Reviewers: Bigcheese, rafael, zturner, mehdi_amini Reviewed by (via email): zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38132 llvm-svn: 314312
* [Support] Remove getPathFromOpenFD, it was unusedReid Kleckner2017-08-041-47/+0
| | | | | | | | | | | | | | Summary: It was added to support clang warnings about includes with case mismatches, but it ended up not being necessary. Reviewers: twoh, rafael Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D36328 llvm-svn: 310078
* Remove Bitrig: LLVM ChangesErich Keane2017-07-211-7/+6
| | | | | | | | Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned. Differential Revision: https://reviews.llvm.org/D35707 llvm-svn: 308799
* Recommit "[Support] Add RetryAfterSignal helper function"Pavel Labath2017-06-291-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The difference from the previous version is the use of decltype, as the implementation of std::result_of in libc++ did not work correctly for variadic function like open(2). Original summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 306671
* Revert "[Support] Add RetryAfterSignal helper function" and subsequent fixPavel Labath2017-06-221-4/+8
| | | | | | | | | | | The fix in r306003 uncovered a pretty fundamental problem that libc++ implementation of std::result_of does not handle the prototype of open(2) correctly (presumably because it contains ...). This makes the whole function unusable in its current form, so I am also reverting the original commit (r305892), which introduced the function, at least until I figure out a way to solve the libc++ issue. llvm-svn: 306005
* [Support] Add RetryAfterSignal helper functionPavel Labath2017-06-211-8/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 305892
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [Solaris] Fix PR33228 - llvm::sys::fs::is_local_impl done rightKamil Rytarowski2017-06-011-0/+5
| | | | | | | | | | | | | | | | | | Summary: Solaris-specific implementation for llvm::sys::fs::is_local_impl. FStype pattern matching might be a bit unreliable, but at least it fixes the build failure. Reviewers: mgorny, nlopes, llvm-commits, krytarowski Reviewed By: krytarowski Subscribers: voskresensky.vladimir, krytarowski Differential Revision: https://reviews.llvm.org/D33695 llvm-svn: 304412
* Revert r303015, because it has the unintended side effect of breakingDimitry Andric2017-05-171-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | driver-mode recognition in clang (this is because the sysctl method always returns one and only one executable path, even for an executable with multiple links): Fix DynamicLibraryTest.cpp on FreeBSD and NetBSD Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303285
* Fix DynamicLibraryTest.cpp on FreeBSD and NetBSDDimitry Andric2017-05-141-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303015
* If posix_fallocate returns EOPNOTSUPP, fallback to ftruncate.Joerg Sonnenberger2017-05-051-4/+5
| | | | | | This can happen at least on NetBSD. llvm-svn: 302263
* Make home_directory look in the password database in addition to $HOME.Zachary Turner2017-03-221-5/+11
| | | | | | | | | | | | | This is something of an edge case, but when the $HOME environment variable is not set, we can still look in the password database to get the current user's home directory. Added a test for this by getting the value of $HOME, then unsetting it, then calling home_directory() and verifying that it succeeds and that the value is the same as what we originally read from the environment. llvm-svn: 298513
* [Support] Fill the file_status struct with link count.Zachary Turner2017-03-201-4/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D31110 llvm-svn: 298326
* Fix linux build.Zachary Turner2017-03-161-1/+2
| | | | llvm-svn: 298007
* [Support] Add support for getting file system permissions on Windows and ↵James Henderson2017-03-161-1/+10
| | | | | | | | | | | | | | | | | | implement sys::fs::set/getPermissions to work with them This change adds support for functions to set and get file permissions, in a similar manner to the C++17 permissions() function in <filesystem>. The setter uses chmod on Unix systems and SetFileAttributes on Windows, setting the permissions as passed in. The getter simply uses the existing status() function. Prior to this change, status() would always return an unknown value for the permissions on a Windows file, making it impossible to test the new function on Windows. I have therefore added support for this as well. On Linux, prior to this change, the permissions included the file type, which should actually be accessed via a different member of the file_status class. Note that on Windows, only the *_write permission bits have any affect - if any are set, the file is writable, and if not, the file is read-only. This is in common with what MSDN describes for their behaviour of std::filesystem::permissions(), and also what boost::filesystem does. The motivation behind this change is so that we can easily test behaviour on read-only files in LLVM unit tests, but I am sure that others may find it useful in some situations. Reviewers: zturner, amccarth, aaron.ballman Differential Revision: https://reviews.llvm.org/D30736 llvm-svn: 297945
* Reverting r297617 because it broke some bots:Aaron Ballman2017-03-131-15/+6
| | | | | | http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/49970 llvm-svn: 297618
* Add support for getting file system permissions and implement ↵Aaron Ballman2017-03-131-6/+15
| | | | | | | | sys::fs::permissions to set them. Patch by James Henderson. llvm-svn: 297617
* Add llvm::sys::fs::real_path.Zachary Turner2017-03-101-1/+63
| | | | | | | | | | | | | | | | | | | | | LLVM already has real_path like functionality, but it is cumbersome to use and involves clean up after (e.g. you have to call openFileForRead, then close the resulting FD). Furthermore, on Windows it doesn't work for directories since opening a directory and opening a file require slightly different flags. So I add a simple function `real_path` which works for all paths on all platforms and has a simple to use interface. In doing so, I add the ability to opt in to resolving tilde expressions (e.g. ~/foo), which are normally handled by the shell. Differential Revision: https://reviews.llvm.org/D30668 llvm-svn: 297483
* fix build on CygwinNuno Lopes2017-03-091-0/+3
| | | | llvm-svn: 297378
* [Support] Add llvm::sys::fs::remove_directories.Zachary Turner2017-03-081-2/+43
| | | | | | | | | | | | | | | | | | | | | We already have a function create_directories() which can create an entire tree, and remove() which can remove an empty directory, but we do not have remove_directories() which can remove an entire tree. This patch adds such a function. Because removing a directory tree can have dangerous consequences when the tree contains a directory symlink, the patch here updates the existing directory_iterator construct to optionally not follow symlinks (previously it would always follow symlinks). The delete algorithm uses this flag so that for symlinks, only the links are removed, and not the targets. On Windows this is implemented with SHFileOperation, which also does not recurse into symbolic links or junctions. Differential Revision: https://reviews.llvm.org/D30676 llvm-svn: 297314
* [fs] Make sure to check S_ISLNK() in fillStatus.Zachary Turner2017-03-071-0/+2
| | | | llvm-svn: 297167
* [Support] Add the option to not follow symlinks on stat.Zachary Turner2017-03-071-2/+2
| | | | llvm-svn: 297154
* [Support] Re-add the special OSX flags on mmap.Zachary Turner2017-02-221-0/+19
| | | | | | | | The problem appears to be that these flags can only be used when mapping a file for read-only, not for readwrite. So we do that here. llvm-svn: 295880
* [Support] Provide linux/magic.h fallback for older kernelsMichal Gorny2017-02-221-0/+15
| | | | | | | | | | | | | | | | | | | | | The function for distinguishing local and remote files added in r295768 unconditionally uses linux/magic.h header to provide necessary filesystem magic numbers. However, in kernel headers predating 2.6.18 the magic numbers are spread throughout multiple include files. Furthermore, LLVM did not require kernel headers being installed so far. To increase the portability across different versions of Linux kernel and different Linux systems, add CMake header checks for linux/magic.h and -- if it is missing -- the linux/nfs_fs.h and linux/smb.h headers which contained the numbers previously. Furthermore, since the numbers are static and the feature does not seem critical enough to make LLVM require kernel headers at all, add fallback constants for the case when none of the necessary headers is available. Differential Revision: https://reviews.llvm.org/D30261 llvm-svn: 295854
* Try to fix the buildbot on OSX.Zachary Turner2017-02-211-16/+0
| | | | | | | | | Since I'm only seeing failures on OSX, and it's saying permission denied, I'm suspecting this is due to the addition of the MAP_RESILIENT_CODESIGN and/or MAP_RESILIENT_MEDIA flags. Speculatively trying to remove those to get the bots working. llvm-svn: 295770
* Try to fix Android build.Zachary Turner2017-02-211-1/+3
| | | | llvm-svn: 295769
* [Support] Add a function to check if a file resides locally.Zachary Turner2017-02-211-3/+63
| | | | | | Differential Revision: https://reviews.llvm.org/D30010 llvm-svn: 295768
* Fix LLDB Android AArch64 GCC debug info buildOmair Javaid2017-02-021-1/+1
| | | | | | | | | Committing after fixing suggested changes and tested release/debug builds on x86_64-linux and arm/aarch64 builds. Differential revision: https://reviews.llvm.org/D29042 llvm-svn: 293850
* [Support] Use O_CLOEXEC only when declaredPavel Labath2017-01-241-2/+20
| | | | | | | | | | | | | | | | | | | Summary: Use the O_CLOEXEC flag only when it is available. Some old systems (e.g. SLES10) do not support this flag. POSIX explicitly guarantees that this flag can be checked for using #if, so there is no need for a CMake check. In case O_CLOEXEC is not supported, fall back to fcntl(FD_CLOEXEC) instead. Reviewers: rnk, rafael, mgorny Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28894 llvm-svn: 292912
* [Support] Add sys::fs::set_current_path() (aka chdir)Pavel Labath2017-01-241-0/+10
| | | | | | | | | | | | | | | Summary: This adds a cross-platform way of setting the current working directory analogous to the existing current_path() function used for retrieving it. The function will be used in lldb. Reviewers: rafael, silvas, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29035 llvm-svn: 292907
* raw_fd_ostream: Make file handles non-inheritable by defaultPavel Labath2017-01-181-2/+2
| | | | | | | | | | | | | | | | Summary: This makes the file descriptors on unix platform non-inheritable (O_CLOEXEC). There is no change in behavior on windows, as the handles were already non-inheritable there. Reviewers: rnk, rafael Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28854 llvm-svn: 292401
* [ThinLTO] Add an API to trigger file-based API for returning objects to the ↵Mehdi Amini2016-12-141-0/+13
| | | | | | | | | | | | | | | | | | | | linker Summary: The motivation is to support better the -object_path_lto option on Darwin. The linker needs to write down the generate object files on disk for later use by lldb or dsymutil (debug info are not present in the final binary). We're moving this into libLTO so that we can be smarter when a cache is enabled and hard-link when possible instead of duplicating the files. Reviewers: tejohnson, deadalnix, pcc Subscribers: dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D27507 llvm-svn: 289631
* Fix comment typos. NFC.Simon Pilgrim2016-11-201-1/+1
| | | | | | Identified by Pedro Giffuni in PR27636. llvm-svn: 287490
OpenPOWER on IntegriCloud