On Thu, Jan 30, 2020 at 09:47:22AM +0000, Andrew Stubbs wrote:
> > By "that much", I mean that while the host vs. offloading target interfaces
> > should be ok due to structure layout done in the host compiler and then
> > streamed to the offloading compiler, there is the problem when the
> > offloaded code interfaces using structures with code natively compiled for
> > the offloading target (newlib), so say calling stat or similar functions
> > wouldn't work well. I'm afraid it won't work well in either offloading
> > model though, in the GCC way struct stat in the offloaded code will be
> > simply the host struct stat with field from there and corresponding
> > structure layout, while in native offloading code probably both different
> > fields and different structure layout, while in the LLVM model I'd assume
> > the offloading code will use the offloading target struct stat, most likely
> > with structure layout from the host.
>
> Stat is not implemented, nor is any other OS call apart from "write", and
> that's only valid for stdout and stderr (aliased to stdout). It's not that
> semi-hosting could not be implemented; it just hasn't been and there's no
> real use case for it (besides making the testsuite happier). If it were to
> be implemented, however, then indeed x86_64 would be significantly simpler
> than ia32, in many cases.
stat was just a random example that first came to my mind, obviously stat
doesn't make much sense in offloading code, but perhaps other functions
that take address of a structure (or reference to it) and are implemented in
the C library (or say libgfortran or libgomp) could. In gomp it is e.g.
omp_*_lock, though both omp_lock_t and omp_nest_lock_t just contain a single
char array member and all that matters is the @OMP_LOCK_SIZE@ and
@OMP_NEST_LOCK_SIZE@ matches in between host and offloading target (would be
enough if offloading target has it smaller).
Jakub
