[cfe-dev] Clang universal driver project state

[Reed Kotler]

Hi Chandler,

The world of compilers for embedded embedded platforms and cross 
compilers is what it is.

Trying to ask the whole embedded programming world to conform to what 
you think it should be is not going to happen; ignoring any questions of 
who is right.

For a given compiler, there are so many platforms, toolchain variants, 
header file variants, library variants. You can't stuff all of this in 
the clang driver.

The driver part of clang is a mess right now. Tons of hardcoded stuff 
that should not be there, even for simple host/targets like linux/linux 
or bsd/bsd. Everyone struggles with trying to do the simplest driver 
work and this kind of activity should be a nobrainer defined by some 
simple ascii based tables that can be edited .

Tablegen is definitely the wrong place. Much of this needs to be 
configurable after the compiler is built.

Gcc deals with this by using configure and essentially you have to build
special compilers for many combinations and even then is not so easy to
keep straight. Using various configure parameters you can control all of 
this but then you have to specially build N compiler binaries; even on 
the same host.

Clang/LLVM tossed out this notion of many compilers on a given host but 
has not adequately addressed the rest of the configuration problem: 
headers, toolchains, libraries, etc.

Simon has already been through this exercise with some very involved 
tool chains for Mips and he knows the issues here.

This is a very simple and clean solution he is proposing.
Clang should be able to read from a simple ascii file where the 
components of the target infrastructure are located: i.e. header files, 
assembler, linker, libraries, etc.

Simon has the time to work on this now and has deep knowledge of the 
details of this problem and did an excellent job on teaching clang about
the code sorcery tool chain for Mips which I think is maybe the most 
involved one of any of the gcc embedded targets.

I think we should focus on what, if anything, really will not work with 
his scheme.

The rest of Clang/LLVM is evolving and maybe the driver will too but I 
can't understand the motivation towards making the current mess there 
even messier by putting more information there.

Reed

On 08/01/2013 01:21 PM, Chandler Carruth wrote:
> On Wed, Jul 31, 2013 at 1:58 AM, Simon Atanasyan
> <simon-AMS08KriifyaMJb+Lgu22Q at public.gmane.org
> <mailto:simon-AMS08KriifyaMJb+Lgu22Q at public.gmane.org>> wrote:
>
>     Hi,
>
>     What is the current state of Clang universal driver project
>     (http://clang.llvm.org/UniversalDriver.html)? Does anybody work on
>     that project now?
>
>     Recently I start to implement support for one more MIPS toolchain.
>     It's directory tree is similar to Code Sourcery toolchain but has some
>     difference as well. Sure I can add a bit more folder names to the
>     clang driver and make GCC detection algorithm more complicated. But I
>     think it is not a right way.
>
>
> I disagree. I think this is the right way.
>
>     That's why I'd like to implement the clang driver's configuration file
>     support. My current plan is to put to this file the following settings
>     and use these settings in the driver:
>     - target triple
>     - include files search paths (-I)
>     - library search paths (-L)
>     - program and files search paths (-B)
>     - explicit paths for files and / or programs
>
>     User will be able to select configuration file by --target=<config
>     name> option.
>
>
> There is not universal agreement that this is the right long-term
> direction. I'm moderately opposed to complicating the distribution and
> installation model of Clang. I'm very opposed to worsening the state of
> getting distributions to both:
> 1) Pick a common and consitent layout of toolchains, and/or
> 2) Work with the upstream community to add support for their layout.
>
> I strongly suspect that doing this the way you are suggesting will have
> this result.
>
>
> The design I have advocated for in the past can be summed up as:
>
> 1) Don't start a new driver. Just refactor the current one.
> 2) Lift the common and often duplicated "configuration" activities from
> C++ code to a simple table file processed by tablegen to produce C++
> code that implements automatic detection of various configurations.
> 3) Continue to bake the database of targets and supported layouts into
> the driver itself, but now with a very low overhead for adding another
> config.
>
> We could eventually add support for loading some elements of these
> configs at runtime, but I would like to avoid that if at all possible,
> and at least ensure that 99.99% of the time it isn't needed.
>
>     Also I want to code an utility that runs specified gcc with
>     -print-multi-directory / -print-prog-name / ... options and generates
>     driver's configuration file.
>
>
> This doesn't ensure they are correct or sensible, just that they happen
> to work today. I would prefer actually being principled about the
> layouts we support.
>
> I would also *really* like to see more pressure on people to produce
> toolchains in a common and widely used layout. Everyone's life would be
> much simpler in that world.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev-Tmj1lob9twqVc3sceRu5cw at public.gmane.org
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>