This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Selecting an architecture tuple for the Rumprun toolchain

Joseph Myers writes ("Re: Selecting an architecture tuple for the Rumprun toolchain"):
> If you would use a different glibc port, but providing access to 
> Linux-specific interfaces, then the tuple would be 
> <arch>-<vendor>-<kernel>-gnu, much like *-*-kfreebsd-gnu describes a glibc 
> port running on the FreeBSD kernel.

As Martin says, rumprun is not using glibc (and is not expected to any
time soon).  So it should not have -gnu.

The problem we are having here is that rumprun doesn't fit in the nice
tidy scheme of these arch tuples.  I think the right thing to do is to
consider how these tuples are usually used, to try to understand how
best to express reality within the existing framework.

There are three contexts for the arch tuple:

 1. Toolstack name prefixes (and header and library path prefixes).

    For this purpose it is necessary to have _different_ names for
    different rumprun targets.  This is necessary because object
    files, libraries, etc. etc., are compiled differently for
    different rumprun execution environments.

    So we need a string in the tuple like `posix' or `xen' which
    indicates the underlying target.

 2. Selecting the correct portability options in existing software

    For this purpose we need primarily to specify that this is netbsd.
    This is because the libc is netbsd, and the system calls, insofar
    as they are useable, are generally very like netbsd.  This should
    appear in the tuple in the place where the libc and/or kernel are
    normally reported.

    We also need to specify the cpu architecture.

 3. Selecting rumpkernel-specific options in rumpkernel-aware software

    Some (rare) software wants to do something special in a rumpkernel
    environment.  So we need to specify `rumprun' or `rumpkernel' or
    something, somewhere.

Existing netbsd seems to use


These considerations lead me to suggest:


We need to wedge the target environemnt and rumprun into the same part
of the tuple because we need existing consumers of the tuple to ignore
it thinking it's an irrelevant `vendor'.

Note that the target environment is nothing like the `kernel'.
rumprun applications do not normally get access to the target
environment.  It does not provide `system calls'.

Indeed rumprun applications are in the usual case deliberately kept
oblivious of the target environment.  So in that sense it does
resemble the `emulation environment' case, and Joseph is right to say
that the application doesn't and shouldn't (normally) need to know.

However, the _user_ does need to know because (as I say) the ABIs,
object formats, header files, etc. etc. etc., are different.  So since
the tuple is used not only to tell the application about the
environment but also by the user to specify how to build, it must
contain this information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]