x86_64 and x32 fail to build

x86_64 and x32 fail to build

[Alexander Monakov]

After recent commits musl fails to build for x86_64 and x32.

When configuring on x86_64, configure mistakenly thinks the host compiler is
going to produce code for x32.  This is because __ILP32__ check wrongly
succeeds.  That is because it's looking for compilation failure due to #error
preprocessor directive, but compilation instead fails because vis.h is not
found (-include vis.h is added to CFLAGS with -I giving the path to it).  I
have used the following patch to proceed with the build:

diff --git a/configure b/configure
index 0e39694..cebee09 100755
--- a/configure
+++ b/configure
@@ -440,7 +440,7 @@ printf "%s\n" "$visibility"
 fi
 
 if test "x$visibility" == xyes ; then
-CFLAGS_AUTO="$CFLAGS_AUTO -include vis.h"
+CFLAGS_AUTO="$CFLAGS_AUTO  -I./arch/$ARCH -I src/internal -I./include -include vis.h"
 CFLAGS_AUTO="${CFLAGS_AUTO# }"
 fi
 

Would be nice to rework trycppif configure function to be robust against this
kind of failures.

When targeting x32, build fails due to "jmp" instruction expecting a 64-bit
argument.  At least the following change is needed, but I'm not sure it's
sufficient: the register should be zero-extended, not sign-extended:

diff --git a/arch/x32/reloc.h b/arch/x32/reloc.h
index 7c72d26..492fbf1 100644
--- a/arch/x32/reloc.h
+++ b/arch/x32/reloc.h
@@ -23,4 +23,4 @@
 #define REL_TPOFF       R_X86_64_TPOFF64
 
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
-	"mov %1,%%esp ; jmp *%0" : : "r"(pc), "r"(sp) : "memory" )
+	"mov %1,%%esp ; jmp *%q0" : : "r"(pc), "r"(sp) : "memory" )


Alexander

Re: x86_64 and x32 fail to build

[Rich Felker]

On Mon, Apr 20, 2015 at 10:21:31PM +0300, Alexander Monakov wrote:
> After recent commits musl fails to build for x86_64 and x32.
> 
> When configuring on x86_64, configure mistakenly thinks the host compiler is
> going to produce code for x32.  This is because __ILP32__ check wrongly
> succeeds.  That is because it's looking for compilation failure due to #error
> preprocessor directive, but compilation instead fails because vis.h is not
> found (-include vis.h is added to CFLAGS with -I giving the path to it).  I
> have used the following patch to proceed with the build:
> 
> diff --git a/configure b/configure
> index 0e39694..cebee09 100755
> --- a/configure
> +++ b/configure
> @@ -440,7 +440,7 @@ printf "%s\n" "$visibility"
>  fi
>  
>  if test "x$visibility" == xyes ; then
> -CFLAGS_AUTO="$CFLAGS_AUTO -include vis.h"
> +CFLAGS_AUTO="$CFLAGS_AUTO  -I./arch/$ARCH -I src/internal -I./include -include vis.h"

This is probably inappropriate. I can think of two reasonable
alternatives; not sure which is better:

1. Have a global CFLAGS_PREDEF that that gets applied to all tests but
   not added to CFLAGS_AUTO.

2. Just use -include src/internal/vis.h.

I kinda like #2 better.

>  CFLAGS_AUTO="${CFLAGS_AUTO# }"
>  fi
>  
> 
> Would be nice to rework trycppif configure function to be robust against this
> kind of failures.
> 
> When targeting x32, build fails due to "jmp" instruction expecting a 64-bit
> argument.  At least the following change is needed, but I'm not sure it's
> sufficient: the register should be zero-extended, not sign-extended:
> 
> diff --git a/arch/x32/reloc.h b/arch/x32/reloc.h
> index 7c72d26..492fbf1 100644
> --- a/arch/x32/reloc.h
> +++ b/arch/x32/reloc.h
> @@ -23,4 +23,4 @@
>  #define REL_TPOFF       R_X86_64_TPOFF64
>  
>  #define CRTJMP(pc,sp) __asm__ __volatile__( \
> -	"mov %1,%%esp ; jmp *%0" : : "r"(pc), "r"(sp) : "memory" )
> +	"mov %1,%%esp ; jmp *%q0" : : "r"(pc), "r"(sp) : "memory" )

+	"mov %1,%%esp ; jmp *%0" : : "r"((uint64_t)(uintptr_t)pc), "r"(sp) : "memory" )

Rich

Re: x86_64 and x32 fail to build

[Alexander Monakov]

> 1. Have a global CFLAGS_PREDEF that that gets applied to all tests but
>    not added to CFLAGS_AUTO.
> 
> 2. Just use -include src/internal/vis.h.
> 
> I kinda like #2 better.

Sure, looks better to me too.

> >  #define CRTJMP(pc,sp) __asm__ __volatile__( \
> > -	"mov %1,%%esp ; jmp *%0" : : "r"(pc), "r"(sp) : "memory" )
> > +	"mov %1,%%esp ; jmp *%q0" : : "r"(pc), "r"(sp) : "memory" )
> 
> +	"mov %1,%%esp ; jmp *%0" : : "r"((uint64_t)(uintptr_t)pc), "r"(sp) : "memory" )

This works, thanks!

Alexander

Re: x86_64 and x32 fail to build

[Alexander Monakov]

Building x32 with --enable-warnings uncovers one leftover unused variable:

diff --git a/arch/x32/syscall_arch.h b/arch/x32/syscall_arch.h
index af67fe3..a3abcf5 100644
--- a/arch/x32/syscall_arch.h
+++ b/arch/x32/syscall_arch.h
@@ -45,7 +45,6 @@ static __inline long __syscall1(long long n, long long a1)
 static __inline long __syscall2(long long n, long long a1, long long a2)
 {
        unsigned long ret;
-       struct __timespec *ts2 = 0;
        switch (n) {
                __fixup_case_2;
        }


When building without --enable-warnings, there are many false positives from
-Wpointer-to-int-cast about x32 __scc(); at least from 4.5 onwards GCC enables
this warning by default, so perhaps if musl really wants to silence it, it
should test the corresponding -Wno-... flag outside of x$warnings == xyes
test?

Thanks.
Alexander

Re: x86_64 and x32 fail to build

[Alexander Monakov]

> When building without --enable-warnings, there are many false positives from
> -Wpointer-to-int-cast about x32 __scc(); at least from 4.5 onwards GCC enables
> this warning by default, so perhaps if musl really wants to silence it, it
> should test the corresponding -Wno-... flag outside of x$warnings == xyes
> test?

Could it be possible that implementation of __scc() can be adjusted to avoid
triggering the warning?  I hoped the following would achieve that:

// Cast X to signed integral type of corresponding size
#define __scc1(X) (__typeof__((X)-(__typeof__(1?(X):0))0)) (X)
#define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) __scc1(X) : (long long) __scc1(X)

... but unfortunately it doesn't work with -Werror=pointer-arith when type of
X is 'void *'.

Alexander

Re: x86_64 and x32 fail to build

[Rich Felker]

On Tue, Apr 21, 2015 at 02:56:27AM +0300, Alexander Monakov wrote:
> > When building without --enable-warnings, there are many false positives from
> > -Wpointer-to-int-cast about x32 __scc(); at least from 4.5 onwards GCC enables
> > this warning by default, so perhaps if musl really wants to silence it, it
> > should test the corresponding -Wno-... flag outside of x$warnings == xyes
> > test?
> 
> Could it be possible that implementation of __scc() can be adjusted to avoid
> triggering the warning?  I hoped the following would achieve that:
> 
> // Cast X to signed integral type of corresponding size
> #define __scc1(X) (__typeof__((X)-(__typeof__(1?(X):0))0)) (X)
> #define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) __scc1(X) : (long long) __scc1(X)
> 
> .... but unfortunately it doesn't work with -Werror=pointer-arith when type of
> X is 'void *'.

Indeed, introducing invalid C to make a warning go away is not a nice
tradeoff.

Rich

Re: x86_64 and x32 fail to build

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

Am Montag, den 20.04.2015, 21:35 -0400 schrieb Rich Felker:
> On Tue, Apr 21, 2015 at 02:56:27AM +0300, Alexander Monakov wrote:
> > > When building without --enable-warnings, there are many false positives from
> > > -Wpointer-to-int-cast about x32 __scc(); at least from 4.5 onwards GCC enables
> > > this warning by default, so perhaps if musl really wants to silence it, it
> > > should test the corresponding -Wno-... flag outside of x$warnings == xyes
> > > test?
> > 
> > Could it be possible that implementation of __scc() can be adjusted to avoid
> > triggering the warning?  I hoped the following would achieve that:
> > 
> > // Cast X to signed integral type of corresponding size
> > #define __scc1(X) (__typeof__((X)-(__typeof__(1?(X):0))0)) (X)
> > #define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) __scc1(X) : (long long) __scc1(X)
> > 
> > .... but unfortunately it doesn't work with -Werror=pointer-arith when type of
> > X is 'void *'.
> 
> Indeed, introducing invalid C to make a warning go away is not a nice
> tradeoff.

Since such a solution would use a gcc'ish extension __typeof__,
anyhow, perhaps it would be preferable to use another one, namely
__builtin_choose_expr:

#define __scc(X) __builtin_choose_expr(sizeof(1?(X):0ULL) < 8, (unsigned long) (X), (long long) (X))

if that helps to quiencen the warning?

(and in any case __scc for x32 should get some () around, just to be
complete)

Jens


-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: x86_64 and x32 fail to build

[Alexander Monakov]

On Tue, 21 Apr 2015, Jens Gustedt wrote:
> Since such a solution would use a gcc'ish extension __typeof__,
> anyhow, perhaps it would be preferable to use another one, namely
> __builtin_choose_expr:
> 
> #define __scc(X) __builtin_choose_expr(sizeof(1?(X):0ULL) < 8, (unsigned long) (X), (long long) (X))
> 
> if that helps to quiencen the warning?

It doesn't help: the warning is still produced for the unevaluated branch of
__builtin_choose_expr, similarly to ternary operator (I tested with gcc-4.8).

My __scc1 could be written a bit simpler:

#define __scc1(X) (__typeof__((X)-(X))) (X)

but still it doesn't work for pointers to void or incomplete types.

Alexander