Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*

[Oleg Endo <oleg dot endo at t-online dot de>]

On Wed, 2015-09-30 at 10:35 -0400, Rich Felker wrote:
> On Wed, Sep 30, 2015 at 10:25:33AM -0400, Rich Felker wrote:
> > On Wed, Sep 30, 2015 at 08:20:38PM +0900, Oleg Endo wrote:
> > > On Tue, 2015-09-29 at 19:58 -0400, Rich Felker wrote:
> > > > Currently sh/fdpic support in binutils is only enabled for
> > > > sh{1,2,}-*-uclinux*. This patch adds it to the sh*-*-linux* targets
> > > > which are what I'm using for musl's j2/sh2 support. sh2eb-*-linux-musl
> > > > toolchains treat the target as regular Linux (modulo no fork and
> > > > resticted mmap), produce binaries which are forward-compatible with
> > > > sh3/4 Linux,
> > > 
> > > Do you already have a suggestion how to encode the atomic model that is
> > > being used by the SH1*/SH2* ELF?  Without at least that, true "forward
> > > compatibility" is difficult to achieve, I guess.
> > 
> > On the musl side, we have all atomics go through a function that
> > chooses which atomic to use based on runtime detection. LLSC (sh4a),
> > GUSA (sh3/4), and imask (sh2 single-core) are supported now and I'm
> > going to add j2 cas.l. For sh4a+ targets, this is optimized out and
> > the inline LLSC atomics are used.

How is this "optimized out" done?

> > On the GCC side, I think we should default to using libatomic except
> > perhaps for sh4a and do the same runtime selection in libatomic.

That'd sort of defeat the purpose of compiler-provided inlined atomic
builtins.  Every atomic op would have to go through a function call.  A
safe but not a very attractive default, e.g. when one wants to build a
SH4-only system.  We can try to lower the function call overhead with
some special atomic library function ABI (as it's done for e.g. shifts
and division libfuncs), if that helps.

> Also note that "encoding the atomic model" (for a fixed model) is not
> useful for forward-compatibility. 

It is useful.  It gives the system a chance of checking the required
capabilities of the binary that is to be executed.  If the system
doesn't implement those requirements, the binary can't run.  I think
it's better to not run a program than running a buggy/misbehaving
program.  At least that way, everybody knows what's wrong.

There are actually even more such things, like floating point ABI (pass
args in GP vs pass in FP regs, default FP mode), or the presence of FP
SW emulation.  E.g. an SH4 system has to provide SW FP library to run
SH2 code, in case it uses FP.  Unless *everything* is linked statically,
of course.

> A program compiled to use imask will
> crash on cpus/kernels with privilege enforcement (although perhaps it
> could trap and emulate).

Yes, that's one option.

>  A program compiled to use imask or GUSA will
> fail to be atomic on multi-core machines.

Not necessarily.  It will have to be restricted to run exclusively on
one core (via processor affinity).  Probably that will require to use
only one particular core for running processes that use imask/gUSA
atomics, because cross process atomics on shared memory will not work
either.  It would run.  The usefulness might be debatable though.

Another option (maybe only viable with an MMU) is patching the binary
code during loading or when downloading code into the flash or
something.  Detecting the compiler generated atomic sequences shouldn't
be that difficult, although it'd be easier and faster if the loader new
where they are (some meta info in the ELF).

>  The failure of GUSA to be
> atomic also affects qemu linux-user; for this reason I got them to
> change the default cpu model for qemu-sh4 to sh4a (and report it via
> hwcap), so that real atomics get used and qemu has a chance to emulate
> them (but I'm still not entirely convinced they work right; emulating
> llsc on a cas-based architecture seems hard).

I'm still puzzled why somebody wanted to run a program/library compiled
for SH2 on e.g. an SH4A multi-core system.  It's easier to just
recompile and redistribute it.  Performance and efficiency is better,
too...

Anyway, I still think there should be more flags or SH attributes in ELF
for encoding all the various ABIs and options.

Cheers,
Oleg