[cfe-dev] Clang Configuration Manager

[Cornel Punga via cfe-dev]

Hi Renato,

Thank you very much for your help!

If I understood correctly, the first thing to implement is a tool that
gathers information about the target, like (you mentioned):
- cpu, OS, etc.
The information gathered at this step will be used to generate the JSON
file / local database. Did I understood correctly?

On the step when target != host, I need to think and research more, because
I do not have a clear image.

Thank you!

În Mar, 13 oct. 2015 la 13:06, Renato Golin <renato.golin at linaro.org> a
scris:

> On 12 October 2015 at 01:35, Cornel Punga via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > I want to work on Configuration Manager open project.
>
> Hi Cornel,
>
> I wrote that spec, so I'll try to give you an overview of what I
> meant. That doesn't mean you have to do exactly that, just to guide
> you on your implementation.
>
>
> > In the description of the project (here) the first step would be to
> build a
> > CFLAGS file. I think it is something similar to the Makefile in the root
> > directory of the Clang, is that right?
>
> No. The idea was to do something similar to "llvm-config", but the
> other way around.
>
> The llvm-config tool, like similar ones, gives you a way to collect
> the flags needed to compile an LLVM based project. What this first
> step would be is to do the same for the hardware.
>
> GCC's structure is largely based on configure-time hard-coded values.
> So, from the same source, you can build a cross-compiler from
> virtually any host to any target, and the defaults and options will be
> restricted to the target arch. LLVM doesn't work like that.
>
> When you build LLVM, you build everything. You can cross-compile from
> one host to any target (if you compile all back-ends) on the same
> binary. Because of that, some options get slightly different
> behaviour, or they're only valid for one or another back-end, or they
> need another options to be set and correct, otherwise things blow up
> badly.
>
> So, there are two side of stage 1:
>
> 1. Identify the host architecture (system introspection), and present
> the best combination of flags (mcpu, mfpu, march, etc) to produce the
> fastest code on the *host*. This will detect the CPU, SIMD,
> co-processors, variations and choose the right options.
>
> 2. Identify the target, when host != target. This is more complicated,
> since however you detect it will depend on the target. If the target
> has an OS, you can telnet/ssh into it and query the system, but some
> OSs will need a server running on the target (Windows?). If the target
> is bare-metal, you'll need some JTAG equivalent, and thus interface
> with drivers on the host system.
>
> This second part would be more of a large collection of tools, rather
> than one single script.
>
> The second stage is to put these scripts into a local database (a JSON
> file would be enough), so that you could choose via Clang
> -mconfig=target-name and it'd automatically detect and pull the config
> from inside Clang. The scripts would still be used to create the
> database, though.
>
>
> > And the last, for now, would Python be a suitable choice for this
> project or
> > better write it in C++?
>
> Python would be perfect.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151013/3b68824f/attachment.html>