summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix
Commit message (Collapse)AuthorAgeFilesLines
* Merging r340751:Hans Wennborg2018-08-302-3/+8
| | | | | | | | | | | | | | | | ------------------------------------------------------------------------ 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
* Add OpenBSD support to the Threading codeBrad Smith2018-06-231-3/+5
| | | | llvm-svn: 335426
* Fix namespaces. No functionality change.Benjamin Kramer2018-06-161-0/+2
| | | | llvm-svn: 334890
* 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
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-121-7/+28
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Fix build errors on some configurationsPavel Labath2018-06-112-3/+3
| | | | | | | | | | | | 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
* Attempt 3: Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-6/+4
| | | | | | | | | | | | | | | | | | I took some liberties and quoted fewer characters than before, based on an article from MSDN which says that only certain characters cause an arg to require quoting. This seems to be incorrect, though, and worse it seems to be a difference in Windows version. The bot that fails is Windows 7, and I can't reproduce the failure on Win 10. But it's definitely related to quoting and special characters, because both tests that fail have a * in the argument, which is one of the special characters that would cause an argument to be quoted before but not any longer after the new patch. Since I don't have Win 7, all I can do is just guess that I need to restore the old quoting rules. So this patch does that in hopes that it fixes the problem on Windows 7. llvm-svn: 334375
* Cleanup. NFCFangrui Song2018-06-102-2/+2
| | | | llvm-svn: 334357
* Revert "Resubmit "[Support] Expose flattenWindowsCommandLine.""Zachary Turner2018-06-101-4/+6
| | | | | | | | | This reverts commit 65243b6d19143cb7a03f68df0169dcb63e8b4632. Seems like it's not a flake. It might have something to do with the '*' character being in a command line. llvm-svn: 334356
* Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-6/+4
| | | | | | | | | There were a few linux compilation failures, but other than that I think this was just a flake that caused the tests to fail. I'm going to resubmit and see if the failures go away, if not I'll revert again. llvm-svn: 334355
* commandLineFitsWithinSystemLimits Overestimates System LimitsAlexander Kornienko2018-06-081-1/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: The function `llvm::sys::commandLineFitsWithinSystemLimits` appears to be overestimating the system limits. This issue was discovered while attempting to enable response files in the Swift compiler. When the compiler submits its frontend jobs, those jobs are subjected to the system limits on command line length. `commandLineFitsWithinSystemLimits` is used to determine if the job's arguments need to be wrapped in a response file. There are some cases where the argument size for the job passes `commandLineFitsWithinSystemLimits`, but actually exceeds the real system limit, and the job fails. `clang` also uses this function to decide whether or not to wrap it's job arguments in response files. See: https://github.com/llvm-mirror/clang/blob/master/lib/Driver/Driver.cpp#L1341. Clang will also fail for response files who's size falls within a certain range. I wrote a script that should find a failure point for `clang++`. All that is needed to run it is Python 2.7, and a simple "hello world" program for `test.cc`. It should run on Linux and on macOS. The script is available here: https://gist.github.com/dabelknap/71bd083cd06b91c5b3cef6a7f4d3d427. When it hits a failure point, you should see a `clang: error: unable to execute command: posix_spawn failed: Argument list too long`. The proposed solution is to mirror the behavior of `xargs` in `commandLinefitsWithinSystemLimits`. `xargs` defaults to 128k for the command line length size (See: https://fossies.org/dox/findutils-4.6.0/buildcmd_8c_source.html#l00551). It adjusts this depending on the value of `ARG_MAX`. Reviewers: alexfh Reviewed By: alexfh Subscribers: llvm-commits Tags: #clang Patch by Austin Belknap! Differential Revision: https://reviews.llvm.org/D47795 llvm-svn: 334295
* Clean up some code in Program.Zachary Turner2018-06-081-0/+2
| | | | | | | | | | NFC here, this just raises some platform specific ifdef hackery out of a class and creates proper platform-independent typedefs for the relevant things. This allows these typedefs to be reused in other places without having to reinvent this preprocessor logic. llvm-svn: 334294
* 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] Use zx_cache_flush on Fuchsia to flush instruction cachePetr Hosek2018-06-061-1/+10
| | | | | | | | | Fuchsia doesn't use __clear_cache, instead it provide zx_cache_flush system call. Use it to flush instruction cache. Differential Revision: https://reviews.llvm.org/D47753 llvm-svn: 334068
* [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] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D47153 llvm-svn: 333307
* Revert 332750, llvm part (see comment on D46910).Nico Weber2018-05-201-1/+1
| | | | llvm-svn: 332823
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D46910 llvm-svn: 332750
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* [Unix] Indent ChangeStd{in,out}ToBinary.Fangrui Song2018-05-161-4/+4
| | | | llvm-svn: 332432
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-161-161/+73
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] pull a function into its own lambdaJF Bastien2018-05-151-19/+21
| | | | | | | | | As requested in D46858, pulling this function into its own lambda makes it easier to read that part of the code and reason as to what's going on because the scope it can be called from is extremely limited. We want to keep it as a function because it's called from the two subsequent lines. llvm-svn: 332325
* [NFC] Update commentsJF Bastien2018-05-151-20/+19
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* [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 @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-305-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* Remove a dead #ifdef.Nico Weber2018-04-301-2/+0
| | | | | | | Unix/Threading.inc should never be included on _WIN32. See also https://reviews.llvm.org/D30526#1082292 llvm-svn: 331151
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-1/+1
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* [cmake] Improve pthread_[gs]etname_np detection codePavel Labath2018-04-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Due to some android peculiarities, in some build configurations (statically linked executables targeting older releases) we could detect the presence of these functions (because they are present in libc.a, where check_library_exists searches), but then fail to build because the headers did not include the definition. This attempts to remedy that by upgrading the check_library_exists to check_symbol_exists, which will check that the function is declared too. I am hoping that a more thorough check will make the messy #ifdef we have accumulated in the code obsolete, so I optimistically try to remove them. Reviewers: zturner, kparzysz, danalbert Subscribers: srhines, mgorny, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D45359 llvm-svn: 330251
* Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArgumentsRui Ueyama2018-04-171-9/+0
| | | | | | | | | | | | | | GetArgumentVector (or GetCommandLineArguments) is very Windows-specific. I think it doesn't make much sense to provide that function from sys::Process. I also made a change so that the function takes a BumpPtrAllocator instead of a SpecificBumpPtrAllocator. The latter is the class to call dtors, but since char * is trivially destructible, we should use the former class. Differential Revision: https://reviews.llvm.org/D45641 llvm-svn: 330216
* 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
* Report fatal error in the case of out of memorySerge Pavlov2018-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* Silence warning about unused private variable.Zachary Turner2018-02-151-1/+3
| | | | llvm-svn: 325275
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-1/+1
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Specify namespace for reallocSerge Pavlov2018-02-151-1/+1
| | | | llvm-svn: 325226
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Fix off-by-one in set_thread_name which causes truncation to fail on LinuxSam McCall2018-02-131-1/+2
| | | | llvm-svn: 325069
* Fallback option for colorized output when terminfo isn't availablePetr Hosek2018-01-191-0/+15
| | | | | | | | | | | Try to detect the terminal color support by checking the value of the TERM environment variable. This is not great, but it's better than nothing when terminfo library isn't available, which may still be the case on some Linux distributions. Differential Revision: https://reviews.llvm.org/D42055 llvm-svn: 322962
* [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
* [ARM][AArch64] Workaround ARM/AArch64 peculiarity in clearing icache.Peter Smith2017-11-281-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | Certain ARM implementations treat icache clear instruction as a memory read, and CPU segfaults on trying to clear cache on !PROT_READ page. We workaround this in Memory::protectMappedMemory by adding PROT_READ to affected pages, clearing the cache, and then setting desired protection. This fixes "AllocationTests/MappedMemoryTest.***/3" unit-tests on affected hardware. Reviewers: psmith, zatrazz, kristof.beyls, lhames Reviewed By: lhames Subscribers: llvm-commits, krytarowski, peter.smith, jgreenhalgh, aemerson, rengolin Patch by maxim-kuvrykov! Differential Revision: https://reviews.llvm.org/D40423 llvm-svn: 319166
* [Support] Support NetBSD PaX MPROTECT in sys::Memory.Lang Hames2017-11-161-123/+4
| | | | | | | | | Removes AllocateRWX, setWritable and setExecutable from sys::Memory and standardizes on allocateMappedMemory / protectMappedMemory. The allocateMappedMemory method is updated to request full permissions for memory blocks so that they can be marked executable later. llvm-svn: 318464
* [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
* Temporary workaround for msan false positive.Sam McCall2017-11-021-1/+1
| | | | llvm-svn: 317203
* [DynamicLibrary] Fix build on musl libcKeno Fischer2017-10-261-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: On musl libc, stdin/out/err are defined as `FILE* const` globals, and their address is not implicitly convertible to void *, or at least gcc 6 doesn't allow it, giving errors like: ``` error: cannot initialize return object of type 'void *' with an rvalue of type 'FILE *const *' (aka '_IO_FILE *const *') EXPLICIT_SYMBOL(stderr); ^~~~~~~~~~~~~~~~~~~~~~~ ``` Add an explicit cast to fix that problem. Reviewers: marsupial, krytarowski, dim Reviewed By: dim Differential Revision: https://reviews.llvm.org/D39297 llvm-svn: 316672
* Don't try to use a non-existent header on FreeBSD/mips.John Baldwin2017-10-251-1/+1
| | | | | | | | Reviewers: dim Differential Revision: https://reviews.llvm.org/D38807 llvm-svn: 316581
OpenPOWER on IntegriCloud