[LLVMdev] The Trouble with Triples

[Richard Pennington]

On 07/09/2015 04:39 AM, David Chisnall wrote:
> On 9 Jul 2015, at 10:25, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
>>> Some people have suggested config files. So we'd have (say)
>>> Targets.cfg on LLVM's source tree copied to the build tree, unless you
>>> specify -DTARGETS_CONFIG=/foo/bar/UbuntuTargets.cfg, and that would
>>> populate the defaults in TargetABI. Of course, this would be a big
>>> change and it's probably for after we do all we already planned to. :)
>> Some of my colleagues from other projects have suggested the same thing off-list. It sounds like a good solution to me. I haven't given much thought to the details yet, but the one concern that springs to mind is that a simple config file (e.g. a triple -> tuple map) is likely to repeat itself a lot, and avoiding that redundancy moves the config file towards a small scripting language. Finding the right balance might be tricky.
> The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly.  We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot.  Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler.
>
> David
>
My slightly modified version of clang, ecc (http:ellcc.org) has been 
using config files for quite a while. I've mentioned them on the mailing 
list before.

In the current implementation, if either the program name (via a 
symlink) or the argument to the -target option matches the name of a 
config file, that file is read and used to control the driver. I used 
the pre-existing YAML parser to parse the config files. A typical config 
file looks like this:

based_on: microblaze-ellcc-linux
compiler:
   options:
     - -target microblaze-ellcc-linux
     - -D__ELK__=1
   c_include_dirs:
     - '$R/include/elk/microblaze'
     - '$R/include/elk'
     - '$R/include/microblaze'
     - '$R/include'
linker:
   options:
     - -Telk.ld
     - -m elf32mb_linux
   static_crt1: $R/lib/microblaze-elk-eng/crt1.o
   dynamic_crt1: $R/lib/microblaze-elk-eng/Scrt1.o
   crtbegin: $R/lib/microblaze-linux-eng/crtbegin.o
   crtend: $R/lib/microblaze-linux-eng/crtend.o

   library_paths:
     - -L$R/lib/microblaze-elk-eng
     - -L$R/lib/elk
     - -L$R/lib/microblaze-linux-eng
   c_libraries:
     - -lelk
     - '-('
     - -lc
     - -lcompiler-rt
     - '-)'

The "based_on" field allows a configuration file to be based on another 
config file. Base config files can be compiled into the driver like 
"microblaze-ellcc-linux" in this example. Other examples of config files 
can be found at http://ellcc.org/viewvc/svn/ellcc/trunk/libecc/config/

-Rich