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.
Prevent 'Line too long for provided buffer'.
We must skip using a buffer of length declared in cbc header, not 4096.
So perform the skip in bytecode.c rather than readdb.c (which doesn't know the
length). The skip in readdb.c is good for skipping the source code, so keep it.
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.
With RLIMIT_DATA > 2GB a 32-bit FreeBSD 7.3 allows ~120M memory to be allocated
via mmap before failing.
With RLIMIT_DATA set to 2GB it allows ~890M memory.
So check the RLIMIT_DATA and set it just below 2G.
You can also just do 'ulimit -d 2097151' to get the effects of this patch.
With -m32 LLVM gets the target arch right, and configure gets it wrong.
LLVM's detection always overrides the arch, so don't warn on these mismatches.
startup.cbc will get the correct arch when JIT is available, which is the only
case where the arch matters anyway.
When there is no JIT the arch reported to startup.cbc will be configure's which might be wrong.
But since there is no JIT startup.cbc shouldn't need to check the arch anyway.
It will still be able to detect sparc vs x86 though, not 32 vs 64-bit.