Wrote configure script from compiling for KLEE. It has several useful
features

- Detects LLVM bitcode compiler independent of what was detected
  at LLVM Configure time (clang and llvm-gcc are supported)

- Detected compiler is tested.

- Supports building native or bitcode library.

- Logging output. Full details logged to 'config.log' file.

- Unlike legacy klee-uclibc there are no
  seperate Rules.mak.* files. Now there is just one.

- Configuration method makes minimal changes to Rules.mak.
  A file Makefile.klee (created by configure) in included
  by Rules.mak. This is done so that merging with upstream uclibc
  will be easier.

- An existing .config file is automatically provided based on
  detected host architecture (only x86_64 supported right now).
Added more stuff to .gitignore (eurgh... I hate building in source)
Applied change originally made by DWD.

It appears that the use of a fixed size buffer was removed for
stdin, stdout and stderr. I'm not sure what rationale behind
doing this was.
Fix build on Linux kernel 3.11.6-1 (Arch Linux)
Added a hack originally added by DWD that prevented compiliation errors.

It seems uClibc provides its own definition of Linux kernel types
that tries to override the native system headers. It did define
_ASM_X86_64_POSIX_TYPES_H

but it appears that is not enough _ASM_X86_POSIX_TYPES_32_H and
_ASM_X86_POSIX_TYPES_64_H also need to be defined to prevent
later inclusion of the system header files (
/usr/include/asm-generic/posix_types.h on my system ).
Apply change originally applied by DWD:

Remove generation of files in libc/sysdeps/linux

This fixes the build by not building target dependent assembly files
(e.g. crtn.o) which are not needed by KLEE. This also disables building
of the system calls in libc/sysdeps/linux/common/*.c .

This really isn't a very good approach. We should consider implementing
a KLEE target in libc/sysdeps/linux so we can call into KLEE's model and
avoid some of the horrible hacks in klee-uclibc.
Added change originally made by CrC (Cristian Cadar?) that
replaces machine specific byteswapping macros with generic ones.

I guess the reason for doing this is to avoid versions that might
use assembly.
Apply change originally applied by DWD:

Change _ISbit macro to support little endian machines. The
implementation looks the same as that used by glibc.
Applied change originally by DWD:

This seems to add more locale categories to the header file. This
seems pointless because it's not required to build uclibc and
currently we don't build applications against uclibc.

Also note that originally DWD applied a similar change to
libc/sysdeps/linux/common/bits/locale.h

that was especially pointless! As the file is not even read as
far as I can tell!
Prevent the building of any version of malloc and friends.

This is done because KLEE has its own internal implementation of
malloc, calloc, realloc and free.
Apply change originally made by DWD and DGU.

The implications of this change are HUGE!

This makes the uclibc following uclibc macros no-ops:

libc_hidden_proto(name, attrs...)
libc_hidden_def(name)
libc_hidden_weak(name)
libc_hidden_ver(local, name)
libc_hidden_data_def(name)
libc_hidden_data_weak(name)
libc_hidden_data_ver(local, name)

These macros do some very clever things that mangle the names. Here
is an example:

// Expansion of libc_hidden_proto(fopen)
extern __typeof (fopen) fopen __asm__ ("" "__GI_fopen") __attribute__ ((visibility ("hidden")));

FILE *fopen(const char * __restrict filename, const char * __restrict mode)
{
 return _stdio_fopen(((intptr_t) filename), mode, ((void *)0), (-1));
}

// Expansion of libc_hidden_def(fopen)
extern __typeof (fopen) __EI_fopen __asm__("" "fopen");
extern __typeof (fopen) __EI_fopen __attribute__((alias ("" "__GI_fopen")));

The effect of this in the resulting LLVM bitcode is the defined function is
does not have symbol name `fopen` but instead `__GI_fopen` and another symbol
is added called `fopen` that is an alias of `__GI_fopen`.

With these macros enabled, internal uclibc functions that call other
uclibc functions call the mangled name (e.g. `__GI_fopen`) instead of
`fopen`.

The original reason for disabling these macros in klee-uclibc was
a bug in LLVM [1] where the alias symbol would be missing.

This bug is no longer present in LLVM (when trying with llvm-gcc 4.2, llvm2.9)
however KLEE was designed around this decision so I encountered a new problem.

System calls will fail, for example programs will try to call `__GI_fcntl` instead
of `fcntl` and because `__GI_fcntl` is **not** defined (we've disabled building it
in klee-uclibc i.e. nothing in libc/sysdeps is built!) this fails.

So it looks like for now I'll have to apply this patch for now. I'm not particularly
happy about this. We really need to re-think how KLEE and klee-uclibc should interact.

[1] http://llvm.org/bugs/show_bug.cgi?id=1655
Apply change originally applied in legacy klee-uclibc

This is a DISGUSTING hack. The added define prevents calling the
function pointers in the following arrays:

extern void (*__preinit_array_start []) (void) attribute_hidden;
extern void (*__preinit_array_end []) (void) attribute_hidden;

Apparently the linker is supposed to define those symbols.

Without this patch KLEE will fail when uclibc initialises because
these arrays are not defined.

This hack probably has other side effects too but this one was
the most obvious to me.
Added a change originally by DWD.

This makes calls to open() and fcntl() made by _stdio_fopen()
go to an undefined externals __libc_open() and __libc_fcntl().

These are treated in specially in KLEE in
linkWithUclibc(llvm::Module *mainModule)

so that they get renamed to calls to KLEE's open() and fcntl()
models.

I don't know why KLEE treats these specially (maybe it's because
of the variable number of arguments issue?)
Apply patch originally made by DWD, CRC and PG (who??)

This patch adds the following behaviour

If KLEE_SYM_PRINTF is defined

- printf and vprintf are defined (they just call vfprintf() )
- fprintf will also always call vfprintf()

By doing this calls to these functions can behave symbolically

if KLEE_SYM_PRINTF is **not** defined (default)

- printf and vprintf are **not** defined so calls to this from
  programs KLEE is executing will try to call externals.

- fprintf will always call vprintf. Because vprintf is no longer
  defined when KLEE is executing a program with a fprintf call
  it will also call vprintf as an external.

By doing this calls to these functions should trigger calls to
external functions and so these functions can no longer handle
symbolic input.

The original comment on this was:
"""
Ok, this is really subtle, but if we are NOT running with symbolic
printfs (for improved speed), we should simply print stdout and
stderr to native stdout using vprintf, but if we are running with
symbolic printfs (for completeness, esp. for cross-checking), we
should always run instrumented code (e.g., vfprintf)
"""
Added change originally made by DWD

I really don't understand why this change was made.

the

also seems very pointless because in the default .config this
code is not even touched because __UCLIBC_HAS_WCHAR__ is defined)