[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20150616163018.GA29231@brightrain.aerifal.cx>
Date: Tue, 16 Jun 2015 12:30:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: "D. Jeff Dionne" <Jeff@...inux.org>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
shumpei.kawasaki@...wc.com, Rob Landley <rob@...dley.net>
Subject: sh2 support is now upstream in musl
As of commit 10d0268ccfab9152250eeeed3952ce3fed44131a, musl now
supports sh2. Some kernel and toolchain tweaks are needed to make this
support useful, though:
- The kernel must be patched to support ELF binaries on NOMMU and to
accept the new unified sh syscal trap number 31. See attached
patches.
- My toolchain was built with musl-cross patches to gcc 4.7.3 (newer
gcc versions break the kernel due to referencing libgcc symbols the
kernel doesn't provide) using TRIPLE=sheb-linux-musl. I was not able
to get it to recognize sh2eb or similar as big-endian, and I also
ended up adding --with-endian=big to GCC_CONFFLAGS just to be safe
(see musl-cross's config.sh).
- All versions of GCC I tried had register allocation errors compiling
musl's complex math code as PIC. I've attached a patch that does a
cheap CFLAGS hack in the makefile to work around these compiler
bugs.
- All executables must be built as PIE. If you only use dynamic
linking, just passing -fPIE and -pie in CFLAGS and LDFLAGS should be
sufficient as long as you remember to do so.
- For static linked PIE, changes to gcc's specs are needed, and it may
be desirable to make changes even if you're doing dynamic linking so
you don't get breakage from forgeting the flags. It's also necessary
to add -fPIC to musl's CFLAGS so that libc.a is built in a form
that's compatible with linking into a PIE program.
Details on specs changes (these are not given as a patch because the
patch will be highly GCC version-/build-specific):
At the beginning of cc1_options, add:
%{D__KERNEL__:;:-fPIE}
Yes the conditional is hideously ugly and "wrong" but it's what the
"esp" patches from Gentoo do and it's needed to avoid horribly
breaking the kernel.
For endfile, change:
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
or similar to:
crtendS.o%s crtn.o%s
i.e. always use crtendS.o (the PIC/PIE compatible version) instead of
the default PIC-incompatible crtend.o. (GCC really should just remove
the PIC-incompatible versions alltogether; they're not useful.) The
same should be done for crtbegin in startfile, but it also needs crt1
work. Change it from something like:
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
to:
%{!shared: %{static:rcrt1.o%s;:Scrt1.o%s}} crti.o%s crtbeginS.o%s
Finally, in link_command, %{pie:-pie} should be replaced with:
%{pie:} %{!nostdlib:%{!r:%{static:-shared -Bsymbolic;:-pie}}}
This causes -pie to always be passed to the linker when producing a
dynamic-linked executable, and enables static-PIE via some magic
linker options when -static is used. This could be handled much better
at the binutils level.
One more thing -- I also changed libgcc to simply be:
-lgcc -lgcc_eh
so that libgcc_s.so is never used. This change should not be necessary
but is preferable anyway.
The above hacking on the specfile can be performed by invoking gcc
with -dumpspecs, saving the output in gcc's lib dir (the one
containing libgcc.a), and editing it. A better approach, however,
would be to edit the GCC source files that the internal specs are
generated from. The widely-used ESP patches (for PIE & SSP by default)
would be a starting point for this.
Rich
View attachment "fdpic_elf_loader.diff" of type "text/plain" (1969 bytes)
View attachment "sh-unified-syscall.diff" of type "text/plain" (654 bytes)
View attachment "musl_sh2_complex_cflags.diff" of type "text/plain" (608 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
