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:25:33 -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>
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.
Rich