This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions
- From: Rich Felker <dalias at libc dot org>
- To: David Howells <dhowells at redhat dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, linux-sh at vger dot kernel dot org, binutils at sourceware dot org, Oleg Endo <oleg dot endo at t-online dot de>, Steven Miao <realmz6 at gmail dot com>
- Date: Thu, 10 Sep 2015 17:09:24 -0400
- Subject: Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions
- Authentication-results: sourceware.org; auth=none
- References: <20150910155059 dot GO17773 at brightrain dot aerifal dot cx> <20150910145808 dot GN17773 at brightrain dot aerifal dot cx> <20150910033400 dot GM17773 at brightrain dot aerifal dot cx> <55F17015 dot 8090207 at redhat dot com> <23476 dot 1441899930 at warthog dot procyon dot org dot uk> <23551 dot 1441900415 at warthog dot procyon dot org dot uk> <20150910160149 dot GP17773 at brightrain dot aerifal dot cx>
On Thu, Sep 10, 2015 at 12:01:49PM -0400, Rich Felker wrote:
> On Thu, Sep 10, 2015 at 04:53:35PM +0100, David Howells wrote:
> > Rich Felker <dalias@libc.org> wrote:
> >
> > > On the other hand, the only existing way to produce a binary that both
> > > (1) needs constant displacement, and (2) actually gets constant
> > > displacement from the kernel at load time, is to manually edit the ELF
> > > headers to flip the bit. So I really doubt any such binaries exist. Do
> > > you have a reason to believe they do?
> >
> > Well, Fujitsu asked for it for FRV - I've no idea whether they have such
> > binaries still.
>
> OK. Can we get feedback from anyone who's actually using this code
> now? I don't see how the current situation is at all acceptable for
> anyone using it, but maybe I'm missing something. It seems programs
> built as FDPIC are going through all the ABI cost for FDPIC (function
> descriptors, restricted relative addressing) for absolutely no gain
> because the kernel just loads them like plain non-FDPIC ELF files...
I've now gotten gcc and my SH-FDPIC port of musl far enough along to
test on a real kernel/hardware, and I can confirm that the kernel's
interpretation of the bit is backwards, at least on SH. Since the code
is the same for all the other archs with FDPIC I think it's safe to
assume they're all broken. Patching the kernel to ignore the bit
yields shared text, as expected.
Rich