This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- From: Rich Felker <dalias at libc dot org>
- To: Oleg Endo <oleg dot endo at t-online dot de>
- Cc: binutils at sourceware dot org
- Date: Wed, 30 Sep 2015 10:35:55 -0400
- Subject: Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- Authentication-results: sourceware.org; auth=none
- References: <20150929235801 dot GA8408 at brightrain dot aerifal dot cx> <1443612038 dot 2509 dot 140 dot camel at t-online dot de> <20150930142533 dot GC8645 at brightrain dot aerifal dot cx>
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.
>
> On the GCC side, I think we should default to using libatomic except
> perhaps for sh4a and do the same runtime selection in libatomic.
Also note that "encoding the atomic model" (for a fixed model) is not
useful for forward-compatibility. A program compiled to use imask will
crash on cpus/kernels with privilege enforcement (although perhaps it
could trap and emulate). A program compiled to use imask or GUSA will
fail to be atomic on multi-core machines. 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).
Rich