From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8807 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: PE target support in configure & Makefile Date: Wed, 4 Nov 2015 20:52:52 -0500 Message-ID: <20151105015252.GV8645@brightrain.aerifal.cx> References: <20151104173955.dc30d64f61e5ec441c34ffd4f788e58e.50d5ba8c08.wbe@email15.secureserver.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446688391 13865 80.91.229.3 (5 Nov 2015 01:53:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 01:53:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8820-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 05 02:53:11 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Zu9jh-0000cq-P0 for gllmg-musl@m.gmane.org; Thu, 05 Nov 2015 02:53:09 +0100 Original-Received: (qmail 32484 invoked by uid 550); 5 Nov 2015 01:53:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32459 invoked from network); 5 Nov 2015 01:53:05 -0000 Content-Disposition: inline In-Reply-To: <20151104173955.dc30d64f61e5ec441c34ffd4f788e58e.50d5ba8c08.wbe@email15.secureserver.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8807 Archived-At: On Wed, Nov 04, 2015 at 05:39:55PM -0700, writeonce@midipix.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