* llvm2.8:
Regenerate configure and Makefile.
LLVM 2.8 changed llvm.mem{cpy,move,set}.* to take 5 arguments.
LLVM 2.8 API update.
Don't cast the iterator directly.
Use CallSite instead of CI->getOperand.
Support building with external LLVM 2.8.
Conflicts:
libclamav/c++/Makefile.in
libclamav/c++/bytecode2llvm.cpp
libclamav/c++/configure
Use AutoUpgrade to upgrade these calls.
Intrinsic::getDeclaration can't be used because in 2.7 it needs 1 type,
in 2.8 it needs 2/3, and there is no function to query how many it needs.
Avoid quadratic load times: run module passes at the end, and run
rtcheck inserter at the end also.
Also optimize away some simple situations that the compiler couldn't,
like result of __is_bigendian() which is a constant at load time (but not at
compile time).
If we would have run LLVM's -O1 optimizers these would have been
optimized already, but we don't do that for 2 reasons:
- optimizations may introduce new bugs
- may take a bit longer time
Just run some simple transforms, and some custom optimizations for the bigendian
case.
GCC (4.4 at least) requires and creates functions with 16-byte stack alignment
on 32-bit Linux too.
If they happen to use SSE instructions they will crash if incoming stack
alignment is not 16-byte.
LLVM claims that 4-byte stack alignment is the standard, and it only aligns to
4-byte, hence the crash. Apparently older versions of GCC/glibc would crash
if it set alignment to 16-byte.
But since the oldest GCC we support is 4.1.2, and disable LLVM on anything older
just set stack alignment to 16-byte for all functions. LLVM will realign stack
as needed. To be safe turn this on only on Linux.
This should really be fixed by either GCC or LLVM, but until that happens (see
LLVM PR8152) lets use this workaround.
bytecode selfcheck running under JIT ran too early, and spawned a thread.
Then clamd forked. threads + fork = bad idea.
So prevent the thread from being spawned in selfcheck mode.
So at the time of fork clamd will still be single threaded as in 0.96.1.
The fix for bb #1924 already fixed most of these, by using the stackprotectreq
attribute to determine if a function was already verified, not to verify it
twice.
However very simple bytecodes don't get that attribute applied. Fix this by
always applying the stackprotect attribute, and checking for that attribute
instead of stackprotectreq.
Detect PaX and fallback to intepreter if needed (bb #2092).
Recent PaX versions deny the RWX mapping, but older versions silently change it
to RW, which causes the program to die as soon as it tries to execute JITed
code.
Add selfcheck on startup (bb #2092).
This will run a very simple bytecode on startup in both JIT and interpreter
mode. The bytecode only calls 1 libclamav API and returns.
Bounds checks were too strict, causing the bytecode to abort when it shouldn't.
This happened when trying to access the last byte of an array, the verifier
was too conservative and considered to be out of bounds, when in fact it wasn't.
This is an update of the runtime verifier from the bytecode compiler.
pthread_cancel is broken on Mac OS X (it only works if the thread
you want to kill calls pthread_testcancel, which is never the situation
when you need async cancelation).
Anyway async cancelation is risky, it may leave bc_ctx in an inconsistent state.
So rather than doing using pthread_cancel (or pthread_kill+siglongjmp)
just insert the timeout checks into the JITed code directly.
These are inserted in each loop, if the loop's tripcount is unknown, or
higher than a threshold. They are also inserted after a certain amount
of APIcalls are made (even in absence of loops).
Note that 'loop' in this sense is not LLVM's notion of a natural loop,
it is simply a BB which is reachable both directly and via a backedge.
For example this doesn't contain natural loops but contains backedges (and a
potential infinite loop):
int foo(int a)
{
int x=4;
if (a == 42)
goto head2;
head:
x++;
head2:
if (a >= 2) {
x += 3;
goto head;
} else if (a >= 0) {
x += 9;
goto head;
}
return x;
}
Common function prototypes must be added only once per Module, otherwise LLVM autorenames
them, and we get llvm.bswap.i326 instead of llvm.bswap.i32, which is of course
not valid and the verifier rejects.
