This ports a missing feature from PathV1.h. I am not sure how to test this
with the regular infrastructure, but an Apple bot should check this when
r183985 is reapplied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184119 91177308-0d34-0410-b5e6-96231b3b80d8
This broke for example the 'not' utility, if a directory called
'FileCheck' is executable and in the path before the actual 'FileCheck'.
This patch steals the implementation of the "old" PathV1 canExecute
implementation:
- checks for R_OK (file readable): this is necessary for executing
scripts; we should not regress here unless we have good reasons
- checks for S_ISREG; if we want to get rid of this, we'd need to
change all callers who already made the assumption when depending
on Path V1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184074 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like clang-tools-extra/unittests/cpp11-migrate/TransformTest.cpp
depends on the behaviour of the old one on Windows. Maybe a difference
between GetCurrentDirectoryA and GetCurrentDirectoryW?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184009 91177308-0d34-0410-b5e6-96231b3b80d8
Execute's Data parameter is now optional, so we won't allocate memory
for it on Windows and we'll close the process handle.
The Unix code should probably do something similar to avoid accumulation
of zombie children that haven't been waited on.
Tested on Linux and Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183906 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183864 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bootstrapping problem with builds for Apple ARM targets.
Clang had the wrong prototype for __clear_cache with ARM targets. Rafael
fixed that in clang svn r181784 and r181810, but without those changes,
we can't build this code for ARM because clang reports an error about the
declaration in Memory.inc not matching the builtin declaration. Some of our
buildbots need to use an older compiler that doesn't have the clang fix.
Since __clear_cache is never used here when __APPLE__ is defined, I'm just
conditionalizing the declaration to match that. I also moved the declaration
of sys_icache_invalidate inside the conditional for __APPLE__ while I was at
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182223 91177308-0d34-0410-b5e6-96231b3b80d8
lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182213 91177308-0d34-0410-b5e6-96231b3b80d8
GCC declares __clear_cache in the gnu modes (-std=gnu++98,
-std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch
declares it and therefore fixes the build when using one of the strict modes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181785 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64 is going to need some kind of cache-invalidation in order to
successfully JIT since it has a weak memory-model. This is provided by
a __clear_cache builtin in libgcc, which acts very much like the
32-bit ARM equivalent (on platforms where it exists).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181129 91177308-0d34-0410-b5e6-96231b3b80d8
The llvm::sys::AddSignalHandler function (as well as related routines) in
lib/Support/Unix/Signals.inc currently registers a signal handler routine
via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or
similar signal, it will show a stack backtrace, deactivate the handler,
and then simply return to the operating system. The intent is that the
OS will now retry execution at the same location as before, which ought
to again trigger the same error condition and cause the same signal to be
delivered again. Since the hander is now deactivated, the OS will take
its default action (usually, terminate the program and possibly create
a core dump).
However, this method doesn't work reliably on System Z: With certain
signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored
by the kernel on the signal stack frame (which is the location where
execution will resume) is not the instruction that triggered the fault,
but then instruction *after it*. When the LLVM signal handler simply
returns to the kernel, execution will then resume at *that* address,
which will not trigger the problem again, but simply go on and execute
potentially unrelated code leading to random errors afterwards.
To fix this, the patch simply goes and re-raises the signal in question
directly from the handler instead of returning from it. This is done
only on System Z and only for those signals that have this particular
problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181010 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used in clang to decide if it should create an @file or not. It
will be tested on the clang side.
Patch by Nathan Froyd.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179285 91177308-0d34-0410-b5e6-96231b3b80d8
If the directory that will contain the unique file doesn't exist when
we tried to create the file, but another process creates it before we
get a chance to try creating it, we would bail out rather than try to
create the unique file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178908 91177308-0d34-0410-b5e6-96231b3b80d8
