Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Neil Jerram]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

2008/5/24 Thiemo Seufer <ths@networkno.de>:

> Neil Jerram wrote:
> >
> > I believe those definitions came from the Boehm GC library.  Do you
> happen
> > to know whether similar improvements have already been applied to Boehm
> GC?
>
> The development version of Boehm GC carries a subset of it since:
>
> http://bdwgc.cvs.sourceforge.net/bdwgc/bdwgc/include/private/gcconfig.h?r1=1.28&r2=1.29
>
> This might be enough to make it work, altough I believe my patch is
> preferable.


OK thanks; I will commit your patch upstream (Guile).  Will you take care of
pushing to Boehm GC, if you want to do that?

> So is it the case that the stack actually grows down on mips (and mipsel
> and
> > powerpc)?
>
> Yes. (This is the the case for almost all machines nowdays.)
>
> > Did you see (or work out) exactly how gcc was outsmarting the
> > test?
>
> No, I only concluded this from the test's incorrect result.


My guess is that unsigned long is only 32-bit, and so truncation of a 64-bit
pointer invalidates the comparison.  Would that make sense?

Google codesearch indicates that other projects use char and char * in this
kind of detection code.  Therefore, if you wouldn't mind trying it out, it
would be interesting to see if the attached patch will also fix this.  (I'm
afraid I currently can't reproduce the seg fault on my own 64-bit test
machines.)

Regards,
        Neil

[-- Attachment #1.2: Type: text/html, Size: 2127 bytes --]

[-- Attachment #2: 0001-Alternate-patch-for-stack-dir-detection.patch --]
[-- Type: application/octet-stream, Size: 923 bytes --]

From b57f14fc44394bec27a594a68b1e60f6b2e1cd2d Mon Sep 17 00:00:00 2001
From: Neil Jerram <nj@dataconnection.com>
Date: Mon, 26 May 2008 18:36:18 +0100
Subject: [PATCH] Alternate patch for stack dir detection

---
 configure.in |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.in b/configure.in
index 0afefad..ac0cacc 100644
--- a/configure.in
+++ b/configure.in
@@ -1099,9 +1099,9 @@ GUILE_STRUCT_UTIMBUF
 #--------------------------------------------------------------------
 
 SCM_I_GSC_STACK_GROWS_UP=0
-AC_TRY_RUN(aux (l) unsigned long l;
-	     { int x; exit (l >= ((unsigned long)&x)); }
-	   main () { int q; aux((unsigned long)&q); },
+AC_TRY_RUN(aux (l) char *l;
+	     { char x; exit (l >= &x); }
+	   main () { char q; aux(&q); },
            [SCM_I_GSC_STACK_GROWS_UP=1],
 	   [],
            [AC_MSG_WARN(Guessing that stack grows down -- see scmconfig.h)])
-- 
1.5.5.1

Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Thiemo Seufer]

Neil Jerram wrote:
> 2008/5/24 Thiemo Seufer <ths@networkno.de>:
> 
> > Neil Jerram wrote:
> > >
> > > I believe those definitions came from the Boehm GC library.  Do you
> > happen
> > > to know whether similar improvements have already been applied to Boehm
> > GC?
> >
> > The development version of Boehm GC carries a subset of it since:
> >
> > http://bdwgc.cvs.sourceforge.net/bdwgc/bdwgc/include/private/gcconfig.h?r1=1.28&r2=1.29
> >
> > This might be enough to make it work, altough I believe my patch is
> > preferable.
> 
> 
> OK thanks; I will commit your patch upstream (Guile).  Will you take care of
> pushing to Boehm GC, if you want to do that?

I'll send a patch upstream.

> > So is it the case that the stack actually grows down on mips (and mipsel
> > and
> > > powerpc)?
> >
> > Yes. (This is the the case for almost all machines nowdays.)
> >
> > > Did you see (or work out) exactly how gcc was outsmarting the
> > > test?
> >
> > No, I only concluded this from the test's incorrect result.
> 
> 
> My guess is that unsigned long is only 32-bit, and so truncation of a 64-bit
> pointer invalidates the comparison.  Would that make sense?
> 
> Google codesearch indicates that other projects use char and char * in this
> kind of detection code.  Therefore, if you wouldn't mind trying it out, it
> would be interesting to see if the attached patch will also fix this.  (I'm
> afraid I currently can't reproduce the seg fault on my own 64-bit test
> machines.)

After a closer look I believe the logic of the test is just plain wrong:

aux (l) unsigned long l;
{ int x; exit (l >= ((unsigned long)&x)); }
main () { int q; aux((unsigned long)&q); },

The test returns true for a downward-growing stack, but that sets
SCM_I_GSC_STACK_GROWS_UP=1 ! For paranoia reasons I checked that
the test behaves the same on mips, powerpc and i386.

Using "(l < ((unsigned long& ..." does the right thing. Amazingly
this means the test is wrong on all platforms, and guile appears to
mostly cope with it. :-)


Thiemo

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Neil Jerram]

2008/5/28 Thiemo Seufer <ths@networkno.de>:
>
> After a closer look I believe the logic of the test is just plain wrong:
>
> aux (l) unsigned long l;
> { int x; exit (l >= ((unsigned long)&x)); }
> main () { int q; aux((unsigned long)&q); },
>
> The test returns true for a downward-growing stack, but that sets
> SCM_I_GSC_STACK_GROWS_UP=1 !

Are you sure you're not missing a step?  According to my
understanding, for a downwards-growing stack:

   &x < l
   => (l >= &x) is TRUE
   => exit status of the test program is non-zero
   => AC_TRY_RUN believes that the test program _failed_
   => SCM_I_GSC_STACK_GROWS_UP stays as 0

> For paranoia reasons I checked that
> the test behaves the same on mips, powerpc and i386.

What exactly do you mean here?  (My guess: that you compiled and ran
the test program by hand, and that the exit status was 1 in each
case?)

> Using "(l < ((unsigned long& ..." does the right thing. Amazingly
> this means the test is wrong on all platforms, and guile appears to
> mostly cope with it. :-)

Unfortunately that is very unlikely, so I'm afraid there is still
something more subtle that we are missing.

Regards,
        Neil

Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Thiemo Seufer]

Neil Jerram wrote:
> 2008/5/28 Thiemo Seufer <ths@networkno.de>:
> >
> > After a closer look I believe the logic of the test is just plain wrong:
> >
> > aux (l) unsigned long l;
> > { int x; exit (l >= ((unsigned long)&x)); }
> > main () { int q; aux((unsigned long)&q); },
> >
> > The test returns true for a downward-growing stack, but that sets
> > SCM_I_GSC_STACK_GROWS_UP=1 !
> 
> Are you sure you're not missing a step?  According to my
> understanding, for a downwards-growing stack:
> 
>    &x < l
>    => (l >= &x) is TRUE
>    => exit status of the test program is non-zero

This is what I saw when running the test manually.

>    => AC_TRY_RUN believes that the test program _failed_
>    => SCM_I_GSC_STACK_GROWS_UP stays as 0

However, config.log shows SCM_I_GSC_STACK_GROWS_UP=1, and that's also
the value used further down the build. Unfortunately the check doesn't 
print a message to that effect, so we can't cross-check with other
build logs. (I only ran guile builds on mips.)

> > For paranoia reasons I checked that
> > the test behaves the same on mips, powerpc and i386.
> 
> What exactly do you mean here?  (My guess: that you compiled and ran
> the test program by hand, and that the exit status was 1 in each
> case?)

Yes, that's what I meant.


Thiemo

Fwd: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Neil Jerram]

[Forwarding this to guile-devel, without the 13M attachment.]

---------- Forwarded message ----------
From: Neil Jerram <neiljerram@googlemail.com>
Date: 2008/5/31
Subject: Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)
To: Thiemo Seufer <ths@networkno.de>
Cc: 481378@bugs.debian.org, guile-devel <guile-devel@gnu.org>


2008/5/29 Thiemo Seufer <ths@networkno.de>:
> Neil Jerram wrote:
>> 2008/5/28 Thiemo Seufer <ths@networkno.de>:
>> >
>> > After a closer look I believe the logic of the test is just plain wrong:
>> >
>> > aux (l) unsigned long l;
>> > { int x; exit (l >= ((unsigned long)&x)); }
>> > main () { int q; aux((unsigned long)&q); },
>> >
>> > The test returns true for a downward-growing stack, but that sets
>> > SCM_I_GSC_STACK_GROWS_UP=1 !
>>
>> Are you sure you're not missing a step?  According to my
>> understanding, for a downwards-growing stack:
>>
>>    &x < l
>>    => (l >= &x) is TRUE
>>    => exit status of the test program is non-zero
>
> This is what I saw when running the test manually.
>
>>    => AC_TRY_RUN believes that the test program _failed_
>>    => SCM_I_GSC_STACK_GROWS_UP stays as 0
>
> However, config.log shows SCM_I_GSC_STACK_GROWS_UP=1, and that's also
> the value used further down the build. Unfortunately the check doesn't
> print a message to that effect, so we can't cross-check with other
> build logs. (I only ran guile builds on mips.)
>
>> > For paranoia reasons I checked that
>> > the test behaves the same on mips, powerpc and i386.
>>
>> What exactly do you mean here?  (My guess: that you compiled and ran
>> the test program by hand, and that the exit status was 1 in each
>> case?)
>
> Yes, that's what I meant.

Thanks.  So, do you agree that my interpretation of what _should_
happen is correct, and that we are therefore looking for a bug
somewhere that can cause a non-zero exit status to map to
SCM_I_GSC_STACK_GROWS_UP=1 ?

Possibilities....

- The compiler.  Is it possible that your compiler doesn't map the arg
of exit(...) to the exit status that the shell sees?

- ./configure code.  Is there a bug in the ./configure code that
confuses the exit status on some platforms only?  Are you still using
the ./configure that came with Guile 1.8.5, or have you regenerated
it?  If the latter, the bug could be being introduced by different
versions of the autotools than the ones we used upstream.

I wish I could reproduce this myself, so I could investigate in
detail!  I've downloaded the Debian package source (for
guile-1.8-1.8.5+1), and built it on an ia64 machine, and I don't see
the problem.  I've attached my ./configure - can you check that it is
the same as the one in the official Debian build (in case I've made a
mistake with the patching process)?

      Neil

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Neil Jerram]

2008/5/31 Neil Jerram <neiljerram@googlemail.com>:
> 2008/5/29 Thiemo Seufer <ths@networkno.de>:
>> Neil Jerram wrote:
>>> 2008/5/28 Thiemo Seufer <ths@networkno.de>:
>>> >
>>> > After a closer look I believe the logic of the test is just plain wrong:
>>> >
>>> > aux (l) unsigned long l;
>>> > { int x; exit (l >= ((unsigned long)&x)); }
>>> > main () { int q; aux((unsigned long)&q); },
>>> >
>>> > The test returns true for a downward-growing stack, but that sets
>>> > SCM_I_GSC_STACK_GROWS_UP=1 !

Another possibility (which came from talking to Stepan Kasal) is that
the code is failing because aux is being inlined.  To avoid this, we
can use instead the find_stack_direction code from Autoconf and
Gnulib, in which find_stack_direction calls itself recursively.

Therefore I've now committed 2 changes upstream which I hope will fix
the current Debian build failures:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=4ff3575c77f95ed5c86970fa93629ba3cfab1912
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=9143131b2766d1e29e05d61b5021395b4c93a6bc

If someone from Debian could try these out on all the architectures,
that would be great.

      Neil

Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

[Ludovic Courtès]

Hi,

"Neil Jerram" <neiljerram@googlemail.com> writes:

> Another possibility (which came from talking to Stepan Kasal) is that
> the code is failing because aux is being inlined.  To avoid this, we
> can use instead the find_stack_direction code from Autoconf and
> Gnulib, in which find_stack_direction calls itself recursively.

Recent versions of GCC can perform tail-call optimizations, which I
thought could be harmful; however, a quick test with GCC 4.2 -O3 on x86
and sparc64 doesn't reveal any problem (no wonder: the assembly code
contains "call find_stack_direction"...).

Thanks,
Ludovic.