Re: [0pf] musl/SH-FDPIC progress

[Rob Landley <rob@landley.net>]

On 09/11/2015 02:05 PM, Rich Felker wrote:
> As noted in the commit message, a patch on the musl side is needed to
> get actual working binaries. I'll post a version of this (not
> appropriate for upstream) soon.

Did you ever write more documentation beyond:

http://www.aerifal.cx/~dalias/binfmts.html

I should add a link to that from the web page, but I dunno if there's
more. I'd like to get a section on nommu.org comparing binflt, static
pie, and fdpic.

Jeff Dionne commented on your toolchain:

> The only issue is he seems to be exclusively targeting fdpic.  The
> issue is you loose a few registers.   I don't know what gcc will do
> performance wise in that case, we need to test.  Hopefully we don't
> need a 'fall back' to bFLT, or something.
>
> A few % hit in an embedded system is a lot...

To which I don't know how to respond. Register starvation mostly seems
to crop up on x86 (where they have horrible behind the scenes hardware
hacks with register renaming and multiple register profiles and so on to
get decent performance out of a lousy assembly design). But sh2 has 16
general purpose registers, which is much less constained...

I'd say "get 'em both out and benchmark them" but the binflt toolchain
I've got (cutting an aboriginal linux release as we speak by the way) is
gcc 4.2.1+binutils 2.17, and yours is something like 8 years later so
the whole code generation backend is basically redone. Not remotely
apples to apples there.

And then there's llvm and you said you got libfirm working? What's
involved in making a libfirm toolchain, trying to build a system with
it, and getting j2 code generation out of it?

Rob