Support "Sourcery CodeBench" MIPS toolchain in the Clang driver


There is a popular standalone "Sourcery CodeBench" toolchain used by
many developers to work with MIPS target platforms. Unfortunately,
Clang driver does not support this toolchain and users have to specify
a lot of command line options to point to the library and include
headers paths, setup SysRoot and provide -B options.

I try to support this toolchain in the Clang driver but bump into some problems.

The "Sourcery CodeBench" toolchain provides various kind of
libc/libstdc++ libraries and headers built for various MIPS target
platform variations: big/little endian, mips64/mips32/mips16,
hard/soft float etc. So when we setup library and include headers
paths, sysroot etc in the Clang driver for this toolchain we have to
take in account not only a target triple (as for regular multiarch
packages supported by Clang) but some other command line options as

The first question - what is the right place for the code which
configures library and include headers paths for "Sourcery CodeBench"
toolchain? As to me I do not want to add new code to the existing
"Linux" toolchain class. I prefer to inherit a new class from "Linux"
to reduce complexity. Is it a right approach?

The second question - how to detect "Sourcery CodeBench" toolchain. I
see a couple of options. The first one is a new Clang command line
option like -mips-toolchain <path to the toolchain>. The second one is
to use existing "-gcc-toolchain" option and try to recognize "Sourcery
CodeBench" toolchain using the option's argument. As to me, adding a
new option is a more explicit way.

The third question - how to setup SysRoot. Now the "Driver" class
holds SysRoot value and is responsible for SysRoot configuration. In
fact it uses --sysroot command line option to override default value.
In case of "Sourcery CodeBench" toolchain, SysRoot path depends on
various command line options. I see a couple of solutions:
a) Move SysRoot maintenance responsibility from Driver to ToolChain
class completely.
b) Keep SysRoot in the Driver class but allow ToolChain successors
adjust SysRoot value if necessary.

Any ideas, objections, comments?