LLVM assumes UTF-8 input, but our args mainly come from the LDC command
line (+ some from the config file and some implicit ASCII ones).
LDC doesn't use UTF-16 on Windows, so afaik, the command-line args are
encoded in the current codepage and so should just be written untouched
into the response file.
writeFileWithEncoding()'s default encoding is UTF-8, meaning no
conversion.
Also check for errors when trying to create and write the response file,
and refactor the executeAndWait() part.
This command line sent to CreateProcess():
"C:\LDC\bin\amd64.bat" 1 2 "3" 4
is internally transformed to:
C:\Windows\system32\cmd.exe /c "C:\LDC\bin\amd64.bat" 1 2 "3" 4
Now guess what - cmd.exe treats the command string after /c or /k in a
very special way if it begins with double quotes and is followed by other
quoted args. In this example, it tries to invoke:
C:\LDC\bin\amd64.bat" 1 2 "3
Another example:
C:\Windows\system32\cmd.exe /c "C:\L D C\bin\amd64.bat" 1 2 "3" 4
=> C:\L
The fix seems to be enclosing the whole command with additional double
quotes (but no additional escaping of the command!) and using /s for
cmd.exe:
C:\Windows\system32\cmd.exe /s /c ""C:\L D C\bin\amd64.bat" 1 2 "3" 4"
So the command is quoted, but not escaped, i.e., no regular argument to
cmd.exe, so we can't use LLVM's executeAndWait() to launch the cmd.exe
process. :/
Additionally, LLVM's arg-quoting code is not public, so we can't use it
to quote & escape the regular args inside the command.
I therefore implemented a simple quoteArgs() variant which should
suffice for our use cases.
If a static library is created then the driver now prepends the
path from -od option to the library name if that name is not
absolute. In case of Linux/Unix, automatic prepending of 'lib'
to the library name is removed.
This fixes failure of runnable/test13774.sh.
Adds a new command line option -mabi= and uses the value to compute
the ABI to use. Adds the ABI to linker and assembler invocation, too.
Allows consistent invocation of the whole tool chain.
Add some of the sanitizer passes to LDC. This is not complete (linking must be
done using clang and the right `-fsanitize=` option) and may not be useful at
all.
If it proves to be usefull then a lot of other options (e.g. blacklist) must be
added.
