The nvptx port [11/11] More tools.

[Jeff Law]

On 10/20/14 08:48, Bernd Schmidt wrote:
> This is a "bonus" optional patch which adds ar, ranlib, as and ld to the
> ptx port. This is not proper binutils; ar and ranlib are just linked to
> the host versions, and the other two tools have the following functions:
>
> * nvptx-as is required to convert the compiler output to actual valid
>    ptx assembly, primarily by reordering declarations and definitions.
>    Believe me when I say that I've tried to make that work in the
>    compiler itself and it's pretty much impossible without some really
>    invasive changes.
> * nvptx-ld is just a pseudo linker that works by concatenating ptx
>    input files and separating them with nul characters. Actual linking
>    is something that happens later, when calling CUDA library functions,
>    but existing build system make it useful to have something called
>    "ld" which is able to bundle everything that's needed into a single
>    file, and this seemed to be the simplest way of achieving this.
>
> There's a toplevel configure.ac change necessary to make ar/ranlib
> useable by the libgcc build. Having some tools built like this has some
> precedent in t-vmsnative, but as Thomas noted it does make feature tests
> in gcc's configure somewhat ugly (but everything works well enough to
> build the compiler). The alternative here is to bundle all these files
> into a separate nvptx-tools package which users would have to download -
> something that would be nice to avoid.
>
> These tools currently require GNU extensions - something I probably
> ought to fix if we decide to add them to the gcc build itself.
Pondering this a bit more, I think this is fine in concept.  As you 
note, removing the GNU extensions or at least making them conditional 
would be good since these are going to be built with the host tools.

I'm not going to dig into the implementations...  I'm going to assume 
the nvptx maintainer (that's highly likely to be you :-) will own their 
care and feeding.

jeff