This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
> abandoned.

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
> root.

Ah, good to know.  So one problem less.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]