summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* 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
* Convenience/safety fix for llvm::sys::Execute(And|No)WaitAlexander Kornienko2017-09-131-6/+6
| | | | | | | | | | | | | | | | | | | | Summary: Change the type of the Redirects parameter of llvm::sys::ExecuteAndWait, ExecuteNoWait and other APIs that wrap them from `const StringRef **` to `ArrayRef<Optional<StringRef>>`, which is safer and simplifies the use of these APIs (no more local StringRef variables just to get a pointer to). Corresponding clang changes will be posted as a separate patch. Reviewers: bkramer Reviewed By: bkramer Subscribers: vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D37563 llvm-svn: 313155
* Minor style fixes in lib/Support/**/Program.(inc|cpp).Alexander Kornienko2017-09-061-32/+30
| | | | | | No functional changes intended. llvm-svn: 312646
* Untabify.NAKAMURA Takumi2017-08-281-4/+4
| | | | llvm-svn: 311875
* [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-212-9/+8
| | | | | | | | Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned. Differential Revision: https://reviews.llvm.org/D35707 llvm-svn: 308799
* Allow clients to specify search order of DynamicLibraries.Frederich Munch2017-07-121-0/+3
| | | | | | | | | | | | | | Summary: Different JITs and other clients of LLVM may have different needs in how symbol resolution should occur. Reviewers: v.g.vassilev, lhames, karies Reviewed By: v.g.vassilev Subscribers: pcanal, llvm-commits Differential Revision: https://reviews.llvm.org/D33529 llvm-svn: 307849
* [Solaris] get rid of _RESTRICT_KYWD warning during the buildKamil Rytarowski2017-07-081-3/+0
| | | | | | | | | | | | | | | | | | Summary: (re)definition of _RESTRICT_KYWD rightfully causes a warning message during the Solaris build. This hack is not needed if build compiler is properly configured (.e.g /usr/bin/gcc) so just remove it. Reviewers: ro, mgorny, krytarowski, joerg Reviewed By: joerg Subscribers: quenelle, llvm-commits Patch by Fedor Sergeev (Oracle). Differential Revision: https://reviews.llvm.org/D35054 llvm-svn: 307469
* [Support] sys::getProcessTriple should return a macOS triple usingAlex Lorenz2017-07-071-6/+19
| | | | | | | | | | | | | | | the system's version of macOS sys::getProcessTriple returns LLVM_HOST_TRIPLE, whose system version might not be the actual version of the system on which the compiler running. This commit ensures that, for macOS, sys::getProcessTriple returns a triple with the system's macOS version. rdar://33177551 Differential Revision: https://reviews.llvm.org/D34446 llvm-svn: 307372
* Recommit "[Support] Add RetryAfterSignal helper function"Pavel Labath2017-06-292-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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-222-7/+17
| | | | | | | | | | | 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-212-17/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Support: chunk writing on LinuxSaleem Abdulrasool2017-06-201-1/+12
| | | | | | | | This is a workaround for large file writes. It has been witnessed that write(2) failing with EINVAL (22) due to a large value (>2G). Thanks to James Knight for the help with coming up with a sane test case. llvm-svn: 305846
* Implement AllocateRWX and ReleaseRWX for NetBSDKamil Rytarowski2017-06-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NetBSD ships with PaX MPROTECT disallowing RWX mappings. There is a solution to bypass this restriction with double mapping RX (code) and RW (data) using mremap(2) MAP_REMAPDUP. The initial mapping must be mmap(2)ed with protection: PROT_MPROTECT(PROT_EXEC). This functionality to bypass PaX MPROTECT appeared in NetBSD-7.99.72. This patch fixes 20 failing tests: - LLVM :: DebugInfo/debuglineinfo-macho.test - LLVM :: DebugInfo/debuglineinfo.test - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_Mips64r2N64_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N32_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N64R6_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32R6_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_i386.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_x86_64.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF-relaxed.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_STT_FILE.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PC8_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_PIC-small-relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_debug_frame.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86_64_StubBuf.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_empty_ehframe.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_DynNoPIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_eh_frame.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s Sponsored by <The NetBSD Foundation> Reviewers: joerg, lhames Reviewed By: joerg Subscribers: sdardis, llvm-commits, arichardson Differential Revision: https://reviews.llvm.org/D33874 llvm-svn: 305650
* [CMake] Introduce LLVM_TARGET_TRIPLE_ENV as an option to override ↵NAKAMURA Takumi2017-06-171-0/+6
| | | | | | | | | | | | | | | | | | | LLVM_DEFAULT_TARGET_TRIPLE at runtime. No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined. If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank, llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE. Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target. Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run; TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/ TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools Differential Revision: https://reviews.llvm.org/D33662 llvm-svn: 305632
* Support: Don't set RLIMIT_AS on child processes when applying a memory limitDavid Blaikie2017-06-121-10/+0
| | | | | | | | | | | | | | | | | | | | | | It doesn't seem relevant to set an address space limit - this isn't important in any sense that I'm aware & it gets in the way of things that use a lot of address space, like llvm-symbolizer. This came up when I realized that bugpoint regression tests were much slower with -gsplit-dwarf than plain -g. Turned out that bugpoint subprocesses (opt, etc) were crashing and doing symbolization - but bugpoint runs those subprocesses with a 400MB memory limit. So with plain -g, mmaping the opt binary would exceed the memory limit, fail, and thus be really fast - no symbolization occurred. Whereas with -gsplit-dwarf, comically, having less to map in, it would succeed and then spend lots of time symbolizing. I've fixed at least the critical part of bugpoint's perf problem there by adding an option to allow bugpoint to disable symbolization. Thus improving the perfromance for -gsplit-dwarf and making the -g-esque speed available without this quirk/accidental benefit. llvm-svn: 305242
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-063-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Close DynamicLibraries in reverse order they were opened.Frederich Munch2017-06-051-1/+2
| | | | | | | | | | | | | | Summary: Matches C++ destruction ordering better and fixes possible problems of loaded libraries having inter-dependencies. Reviewers: efriedma, v.g.vassilev, chapuni Reviewed By: efriedma Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33652 llvm-svn: 304720
* Fix building DynamicLibrary.cpp with musl libcDimitry Andric2017-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: The workaround added in rL301240 for stderr/out/in symbols being both macros and globals is only necessary for glibc, and it does not compile with musl libc. Alpine Linux has had the following fix for it: https://git.alpinelinux.org/cgit/aports/plain/main/llvm4/llvm-fix-DynamicLibrary-to-build-with-musl-libc.patch Adapt the fix in our DynamicLibrary.inc for Unix. Reviewers: marsupial, chandlerc, krytarowski Reviewed By: krytarowski Subscribers: srhines, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33883 llvm-svn: 304707
* [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
* Remove spurious cast of nullptr. NFC.Serge Guelton2017-05-111-2/+2
| | | | | | Conversion rules allow automatic casting of nullptr to any pointer type. llvm-svn: 302780
* If posix_fallocate returns EOPNOTSUPP, fallback to ftruncate.Joerg Sonnenberger2017-05-051-4/+5
| | | | | | This can happen at least on NetBSD. llvm-svn: 302263
* fix build on CygwinNuno Lopes2017-05-051-1/+1
| | | | llvm-svn: 302246
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-271-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301562
* Revert "Refactor DynamicLibrary so searching for a symbol will have a ↵Frederich Munch2017-04-241-131/+0
| | | | | | | | | | defined order" The i686-mingw32-RA-on-linux bot is still having errors. This reverts commit r301236. llvm-svn: 301240
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-241-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301236
* Revert "Refactor DynamicLibrary so searching for a symbol will have a ↵Frederich Munch2017-04-241-131/+0
| | | | | | | | | | defined order.” The changes are causing the i686-mingw32 build to fail. This reverts commit r301153, and the changes for a separate warning on i686-mingw32 in r301155 and r301156. llvm-svn: 301157
* Refactor DynamicLibrary so searching for a symbol will have a defined order andFrederich Munch2017-04-241-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | libraries are properly unloaded when llvm_shutdown is called. Summary: This was mostly affecting usage of the JIT, where storing the library handles in a set made iteration unordered/undefined. This lead to disagreement between the JIT and native code as to what the address and implementation of particularly on Windows with stdlib functions: JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv Native: getenv("TEST") -> NULL // called ucrt.dll, getenv Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows not giving priority to the process' symbols as it did on Unix. Reviewers: chapuni, v.g.vassilev, lhames Reviewed By: lhames Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D30107 llvm-svn: 301153
OpenPOWER on IntegriCloud