[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151105015252.GV8645@brightrain.aerifal.cx>
Date: Wed, 4 Nov 2015 20:52:52 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: PE target support in configure & Makefile
On Wed, Nov 04, 2015 at 05:39:55PM -0700, writeonce@...ipix.org wrote:
> Greetings,
>
> As many of you know, musl has been ported to winnt (and has an already
> working bash/dash, core shell utilities, and a native toolchain) without
> applying any patches to the upstream source tree.[1] Thus far, however,
> we have been building musl using a deviant script that we now hope to
> retire.
Thanks for the report/info/patch. Since build system overhaul is
already on the roadmap for this release cycle, I'm including some
general comments on things that could be changed as part of this reply
where they're related to things you want to change.
> As musl's build system is currently being revisited, I would like
> propose (with the attached patch as a reference) the addition of the
> following features:
>
> 1. add rules for $(ARCH)/%.c: C-language arch-specific files.
After discussing this briefly on IRC I think this is a change that
would be welcome in general as part of the build overhaul in this
release cycle. There are actually a number of reasons we might want to
transition from asm source files to C files with inline asm for _most_
(not all; see below) of the arch-specific asm:
- Enabling LTO inlining.
- Ability to generate code for multiple calling conventions/ABIs from
the same sources.
- Eliminating the issue of missing CFI in asm source files.
- Eliminating most ugly non-code directives in asm source files.
Of course some functions cannot be written in C at all: mainly vfork,
setjmp, the tlsdesc functions, and anything else that returns twice or
has a nonstandard calling convention.
No decision needs to be made at this time however; enabling arch
replacements via C files in addition to just asm files does not
require that we change anything.
> 2. --arch=ARCH: alternate arch-specific source files.
> at the present, ARCH is derived from TARGET and has no corresponding
> configure switch. Adding --arch support would allow setting nt32 and
> nt64 as the arch directories for winnt's i686 and x86_64 targets,
> respectively.
I think this should be derived from target (by default, obtained from
$CC -dumpmachine). Adding yet another option that can be set
inconsistently and which has not-widely-known interaction with the
standard options seems like a bad idea.
> 3. PE target detection, shared library linker flags.
> at the present, musl's configure script assumes ELF targets as well as
> its own loader routine (_dlstart). PE target support could be added with
> only a minimal effort if we a) detect PE targets using the compiler, and
> b) set PE/ELF-specific linker flags accordingly.
See my comments below interleaved with the patch.
> diff -u musl-1.1.12/configure musl-1.1.12.alt/configure
> --- musl-1.1.12/configure 2015-10-19 19:12:57.000000000 -0400
> +++ musl-1.1.12.alt/configure 2015-11-04 18:08:50.676855247 -0500
> @@ -22,6 +22,7 @@
> System types:
> --target=TARGET configure to run on target TARGET [detected]
> --host=HOST same as --target
> + --arch=ARCH use alternate ARCH-specific source files for TARGET
>
> Optional features:
> --enable-optimize=... optimize listed components for speed over size [auto]
> @@ -166,6 +167,7 @@
> --enable-gcc-wrapper|--enable-gcc-wrapper=yes) wrapper=yes ; gcc_wrapper=yes ;;
> --disable-gcc-wrapper|--enable-gcc-wrapper=no) wrapper=no ;;
> --enable-*|--disable-*|--with-*|--without-*|--*dir=*|--build=*) ;;
> +--arch=*) ARCH=${arg#*=} ;;
> --host=*|--target=*) target=${arg#*=} ;;
> -* ) echo "$0: unknown option $arg" ;;
> CC=*) CC=${arg#*=} ;;
> @@ -280,7 +282,7 @@
> #
> # Convert to just ARCH
> #
> -case "$target" in
> +test -z "$ARCH" && case "$target" in
> # Catch these early to simplify matching for 32-bit archs
> mips64*|powerpc64*) fail "$0: unsupported target \"$target\"" ;;
> arm*) ARCH=arm ;;
> @@ -504,6 +506,10 @@
> CFLAGS_AUTO="${CFLAGS_AUTO# }"
> fi
>
> +# detect PE targets
> +test -z "$PE_TARGET" && "$CC" -dM -E - < /dev/null \
> + | grep __PE__ >/dev/null && PE_TARGET=yes
> +
> # Some patched GCC builds have these defaults messed up...
> tryldflag LDFLAGS_AUTO -Wl,--hash-style=both
Why not just use the $ARCH names for midipix rather than probing the
compiler for something you already know?
> @@ -513,7 +519,7 @@
> # runtime library; implementation error is also a possibility.
> tryldflag LDFLAGS_AUTO -Wl,--no-undefined
>
> -test "$shared" = "no" || {
> +test "$shared" = "no" || test "$PE_TARGET" = "yes" || {
> # Disable dynamic linking if ld is broken and can't do -Bsymbolic-functions
> LDFLAGS_DUMMY=
> tryldflag LDFLAGS_DUMMY -Wl,-Bsymbolic-functions || {
> @@ -523,6 +529,19 @@
> }
> }
I think we can actually make -Bsymbolic-functions optional and just
detect it. As an aside, we could support interposing malloc (a widely
requested feature, though one that requires a lot of care to make
safe) by using --dynamic-list-data and --dynamic-list FILE, where FILE
contains a list of the malloc-related symbols, instead of
-Bsymbolic-functions. Or we could just drop it alltogether and let
visibility do the work for us instead.
> +# PE/ELF-specific LDFLAGS
> +test "$shared" = "no" || {
> +
> +test "$PE_TARGET" = "yes" && "$CC" -dM -E - < /dev/null \
> + | grep __SIZEOF_POINTER__ | grep 4 >/dev/null && underscore='_'
> +
> +test "$PE_TARGET" = "yes" && \
> + LDFLAGS_IMG_FMT="-Wl,-e,${underscore}__libc_entry_point -Wl,--subsystem,windows"
> +
> +test "$PE_TARGET" = "yes" || \
> + LDFLAGS_IMG_FMT="-Wl,-e,_dlstart -Wl,-Bsymbolic-functions"
> +}
Why not just arrange for the name to always be the same at the C
source level by using one fewer underscore in the 32-bit version?
Complex logic like this should be minimized at the configure level.
Rich
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.
