This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: binutils at sourceware dot org
- Date: Mon, 05 Oct 2015 21:28:52 +0900
- Subject: Re: [PATCH] enable fdpic targets/emulations for sh*-*-linux*
- Authentication-results: sourceware.org; auth=none
- References: <20150930143555 dot GD8645 at brightrain dot aerifal dot cx> <1443627005 dot 2509 dot 189 dot camel at t-online dot de> <20150930183810 dot GE8645 at brightrain dot aerifal dot cx> <1443715139 dot 2031 dot 134 dot camel at t-online dot de> <20151001164630 dot GI8645 at brightrain dot aerifal dot cx> <1443804962 dot 2031 dot 290 dot camel at t-online dot de> <20151002175223 dot GU8645 at brightrain dot aerifal dot cx> <1443863059 dot 2031 dot 433 dot camel at t-online dot de> <20151003185947 dot GC8645 at brightrain dot aerifal dot cx> <1443929574 dot 2031 dot 506 dot camel at t-online dot de> <20151005022655 dot GI8645 at brightrain dot aerifal dot cx>
On Sun, 2015-10-04 at 22:26 -0400, Rich Felker wrote:
> The ABI is a contract between multiple components, possibly with
> diverse maintainers and users. From my perspective, treating it as
> something you can just change at whim is irresponsible -- especially
> without any evidence that doing so is even going to have measurable
> benefits -- and not the way to establish a platform as something
> mature and attractive to developers/users.
Yes, that might be true. My only point is that the tools should provide
some degree of flexibility, which allow one to try out (benchmark,
measure, etc) different ABI options in the first place. I don't have a
strong opinion on which ABI should be the default.
> Note that changing this would require changes in at least libc and
> binutils, and probably also gcc, and you would need matching versions
> of all of them. And I have no idea if there are other third-party
> tools that would also be affected.
In this case, don't change it.
> LLVM does not yet support SH but we
> want it to.
I'm very curious to see that.
> The MIPS trap probably takes 1000+ cycles (actually I'm looking for
> someone with the real hardware to test it so we can make reasonable
> cost assessments based on this in musl). So we're looking at
> completely different scales of "bad performance".
This sounds slow indeed. On SH I'd expect emulation of a missing LLCS
instruction via an illegal instruction exception to be < 50 cycles.
Depending on what exactly it has to do to make it work. I haven't tried
it myself and my expectation could be totally off.
> I think that's a big risk for both users and for us. You've commented
> yourself on how stuff (other than Linux, but same issue) has a history
> of getting developed in a fork that eventually bitrots and gets
That's why I was suggesting to update it from mainline frequently and
try to get it upstream when it's mature enough. It's your call.
> > Yes, that's what I was saying. Except that using hard-float
> > "internally" and soft-float "externally" is not supported by the
> > compiler at the moment.
> This would be nice to add. After finishing FDPIC I'll look into it.
> ABI and instruction use should be separate options, not conflated.
> Presumably this should not involve much work beyond identifying which
> conditionals need to be on "has fpu" and which need to be on "using
> hardfloat ABI".
Patches for GCC a certainly welcome.
> > AFAIK, there is also no mechanism for the dynamic linker to pick the
> > right libraries. E.g. when loading an SH2-nofpu ELF on an SH4-fpu
> > system, it should pick the SH2-nofpu compatible libraries.
> For musl there already is. Each ABI has its own dynamic linker/libc,
> which in turn has its own library path configuration file. This same
> approach allows us even to have multiple archs on the same filesystem
Ah, good to know. So one problem less.