[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 04 Nov 2015 19:18:24 -0700
From: <writeonce@...ipix.org>
To: musl@...ts.openwall.com
Subject: RE: PE target support in configure & Makefile
On 11/04/2015 08:52 PM, Rich Felker wrote:
> 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.
>
That works too, of course, but would require special-casing the PE
targets since -dumpmachine returns x86_64-nt64-midipix
(i686-nt32-midipix), whereas the arch-specific files are in nt64 (nt32).
>> 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?
>
Indeed. And if end up special-casing the targets for ARCH, then
PE_TARGET should probably be set as part of that same check.
>> @@ -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.
Indeed :-)
>
> 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.
