[PATCH] AMD GCN Port

[Jeff Johnston]

Hi Andrew,

Just one issue.  You are putting your syscalls into the machine directory.
This is no longer done anymore.
Some older ports had syscalls in the sys directory, but were encouraged to
use libgloss instead to allow the user to
specify syscalls on the link (e.g. linking for a simulator vs board config
A vs board config B).

Arm is a pecularity in that they have their syscalls duplicated in both the
libc/sys and libgloss directories.  There is a configuration
option (--disable-newlib-supplied-syscalls) which is used by them to
disable the newlib syscalls so that a user may use libgloss
to substitute the syscalls for various board set-ups.  It is a bit of a
hack and requires dual maintenance.

I would suggest you look at having your syscalls in libgloss at the start.
If you are certain there will never be a need for linking in different
versions, you can put them in libc/sys with have_crt0="no".

-- Jeff J.



On Thu, Jan 10, 2019 at 7:36 AM Andrew Stubbs <ams@codesourcery.com> wrote:

> Hi all,
>
> The GCC port to the AMD GCN architecture (used in GPUs) will be
> committed soon (I hope), so here is the Newlib port to go with it.
>
> The patch includes enough to run most of the GCC testsuite, and
> therefore most of what users will need for OpenACC/OpenMP offloading.
> I've omitted the config.sub and the generated files from the patch, but
> I would add those before committing.
>
> Because GCN is a GPU architecture there is no real support for I/O. The
> "gcn-run" stand-alone launcher program, and libgomp offload launcher
> (both included with GCC), feature a shared-memory interface to implement
> input arguments, return code, and stdout, but that's all.
>
> On the other hand, because it's a GPU architecture, we absolutely need
> to handle re-entrancy -- there can be hundreds of hardware threads
> running at once -- so the port uses __DYNAMIC_REENT__ and malloc locks.
>
> The port still needs a lot more stub functions for system calls, if it
> is to support Fortran write, for example, but those can wait for another
> time.
>
> OK to commit once GCC is done? (I will also retest at that time.)
>
> --
> Andrew Stubbs
> Mentor Graphics / CodeSourcery
>