Guile FTBFS on hppa - problem in detecting stack direction?

Guile FTBFS on hppa - problem in detecting stack direction?

[Neil Jerram]

Hi hppa people!  I'm hoping you can help me fix a FTBFS that we're
getting with Guile on hppa.

The build log is here:
http://buildd.debian.org/fetch.cgi?pkg=guile-1.8;ver=1.8.5%2B1-2;arch=hppa;stamp=1217809852

The specific problem is a segmentation fault, at a point in a build
that probably won't mean anything to non-Guile folks - but the key
point is that we were recently seeing exactly the same segmentation
fault (i.e. at the same place) on several other architectures (mips,
mipsel, powerpc), and that was caused by the code in configure.in not
detecting the stack direction properly.

This patch - http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=9143131b2766d1e29e05d61b5021395b4c93a6bc
- fixed the problem for mips, mipsel and powerpc, but it looks as
though we are still getting the stack direction wrong on hppa.  (My
understanding is that on hppa the stack actually grows upwards,
whereas on most platforms it's downwards.)

I've appended the relevant bit of configure.in below.  Can anyone help
with why this might not be working on hppa?

Thanks,
       Neil

#--------------------------------------------------------------------
#
# Which way does the stack grow?
#
# Following code comes from Autoconf 2.61's internal _AC_LIBOBJ_ALLOCA
# macro (/usr/share/autoconf/autoconf/functions.m4).  Gnulib has
# very similar code, so in future we could look at using that.
#
# An important detail is that the code involves find_stack_direction
# calling _itself_ - which means that find_stack_direction (or at
# least the second find_stack_direction() call) cannot be inlined.
# If the code could be inlined, that might cause the test to give
# an incorrect answer.
#--------------------------------------------------------------------

SCM_I_GSC_STACK_GROWS_UP=0
AC_CACHE_CHECK([stack direction],
	       [SCM_I_GSC_STACK_GROWS_UP],
[AC_RUN_IFELSE([AC_LANG_SOURCE(
[AC_INCLUDES_DEFAULT
int
find_stack_direction ()
{
  static char *addr = 0;
  auto char dummy;
  if (addr == 0)
    {
      addr = &dummy;
      return find_stack_direction ();
    }
  else
    return (&dummy > addr) ? 1 : -1;
}

int
main ()
{
  return find_stack_direction () < 0;
}])],
	       [SCM_I_GSC_STACK_GROWS_UP=1],
	       [],
	       [AC_MSG_WARN(Guessing that stack grows down -- see scmconfig.h)])])

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Kyle McMartin]

On Wed, Aug 06, 2008 at 09:38:32PM +0100, Neil Jerram wrote:
> Hi hppa people!  I'm hoping you can help me fix a FTBFS that we're
> getting with Guile on hppa.
> 
> The build log is here:
> http://buildd.debian.org/fetch.cgi?pkg=guile-1.8;ver=1.8.5%2B1-2;arch=hppa;stamp=1217809852
> 
> The specific problem is a segmentation fault, at a point in a build
> that probably won't mean anything to non-Guile folks - but the key
> point is that we were recently seeing exactly the same segmentation
> fault (i.e. at the same place) on several other architectures (mips,
> mipsel, powerpc), and that was caused by the code in configure.in not
> detecting the stack direction properly.
> 
> This patch - http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=9143131b2766d1e29e05d61b5021395b4c93a6bc
> - fixed the problem for mips, mipsel and powerpc, but it looks as
> though we are still getting the stack direction wrong on hppa.  (My
> understanding is that on hppa the stack actually grows upwards,
> whereas on most platforms it's downwards.)
> 
> I've appended the relevant bit of configure.in below.  Can anyone help
> with why this might not be working on hppa?
> 

According to the build.log,

checking stack direction... (cached) 0

this looks like it's obtaining the wrong result...

I'm not entirely sure why... what optimization pass is being used to
build this?

regards, Kyle

> Thanks,
>        Neil
> 
> #--------------------------------------------------------------------
> #
> # Which way does the stack grow?
> #
> # Following code comes from Autoconf 2.61's internal _AC_LIBOBJ_ALLOCA
> # macro (/usr/share/autoconf/autoconf/functions.m4).  Gnulib has
> # very similar code, so in future we could look at using that.
> #
> # An important detail is that the code involves find_stack_direction
> # calling _itself_ - which means that find_stack_direction (or at
> # least the second find_stack_direction() call) cannot be inlined.
> # If the code could be inlined, that might cause the test to give
> # an incorrect answer.
> #--------------------------------------------------------------------
> 
> SCM_I_GSC_STACK_GROWS_UP=0
> AC_CACHE_CHECK([stack direction],
> 	       [SCM_I_GSC_STACK_GROWS_UP],
> [AC_RUN_IFELSE([AC_LANG_SOURCE(
> [AC_INCLUDES_DEFAULT
> int
> find_stack_direction ()
> {
>   static char *addr = 0;
>   auto char dummy;
>   if (addr == 0)
>     {
>       addr = &dummy;
>       return find_stack_direction ();
>     }
>   else
>     return (&dummy > addr) ? 1 : -1;
> }
> 
> int
> main ()
> {
>   return find_stack_direction () < 0;
> }])],
> 	       [SCM_I_GSC_STACK_GROWS_UP=1],
> 	       [],
> 	       [AC_MSG_WARN(Guessing that stack grows down -- see scmconfig.h)])])
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Carlos O'Donell]

On Wed, Aug 6, 2008 at 4:38 PM, Neil Jerram <neiljerram@googlemail.com> wrote:
> I've appended the relevant bit of configure.in below.  Can anyone help
> with why this might not be working on hppa?

Please don't try to detect stack growth direction. It's part of the
ABI. Select it based on the canonical target triplet.

Cheers,
Carlos.

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Bernhard R. Link]

* Carlos O'Donell <carlos@systemhalted.org> [080807 03:41]:
> On Wed, Aug 6, 2008 at 4:38 PM, Neil Jerram <neiljerram@googlemail.com> wrote:
> > I've appended the relevant bit of configure.in below.  Can anyone help
> > with why this might not be working on hppa?
> 
> Please don't try to detect stack growth direction. It's part of the
> ABI. Select it based on the canonical target triplet.

Just because something is part of some ABI is no reason to not try to
autodetect it. It's an elementary philisophical idea behind autoconf
(and one of its biggest advantages in my POV) that you do not check for
the system but for its features[1].
This allows it to support most new platforms for most programs out of
the box (and not fail if anything changes anywhere).

There are some reasons to sometimes depart from that rule, when things
are too hard to check or too subtle to break. But just that this
information can be deduced from some triplet in alone is no reason at
all.

Hochachtungsvoll,
	Bernhard R. Link

[1] Most autoconf/automake generated build systems (that do not use
libtool) can even work without any config.guess and config.sub scripts,
so just be run on any architecture not even created when the source was
created.

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Carlos O'Donell]

On Wed, Aug 6, 2008 at 4:38 PM, Neil Jerram <neiljerram@googlemail.com> wrote:
> SCM_I_GSC_STACK_GROWS_UP=0

Move this line.

> AC_CACHE_CHECK([stack direction],
>               [SCM_I_GSC_STACK_GROWS_UP],
> [AC_RUN_IFELSE([AC_LANG_SOURCE(
> [AC_INCLUDES_DEFAULT
> int
> find_stack_direction ()
> {
>  static char *addr = 0;
>  auto char dummy;
>  if (addr == 0)
>    {
>      addr = &dummy;
>      return find_stack_direction ();
>    }
>  else
>    return (&dummy > addr) ? 1 : -1;
> }
>
> int
> main ()
> {
>  return find_stack_direction () < 0;
> }])],
>               [SCM_I_GSC_STACK_GROWS_UP=1],
>               [],

Into this empty bracket.

>               [AC_MSG_WARN(Guessing that stack grows down -- see scmconfig.h)])])

Tell me if that fixes your problem with cached variable detection.

Cheers,
Carlos.

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Carlos O'Donell]

On Thu, Aug 7, 2008 at 5:49 AM, Bernhard R. Link <brlink@debian.org> wrote:
> There are some reasons to sometimes depart from that rule, when things
> are too hard to check or too subtle to break. But just that this
> information can be deduced from some triplet in alone is no reason at
> all.

I believe that we both understand the design principles, but disagree
on where we choose to draw the line :-)

Cheers,
Carlos.

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Neil Jerram]

2008/8/7 Carlos O'Donell <carlos@systemhalted.org>:
> On Wed, Aug 6, 2008 at 4:38 PM, Neil Jerram <neiljerram@googlemail.com> wrote:
>> SCM_I_GSC_STACK_GROWS_UP=0
>
> Move this line. [...]

> Tell me if that fixes your problem with cached variable detection.
>
> Cheers,
> Carlos.

Many thanks.  I haven't tried it yet, but I expect you are right;
sorry for making such a silly mistake!

Regards,
            Neil

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Greg Troxel]

"Bernhard R. Link" <brlink@debian.org> writes:

> * Carlos O'Donell <carlos@systemhalted.org> [080807 03:41]:
>
> Just because something is part of some ABI is no reason to not try to
> autodetect it. It's an elementary philisophical idea behind autoconf
> (and one of its biggest advantages in my POV) that you do not check for
> the system but for its features[1].
> This allows it to support most new platforms for most programs out of
> the box (and not fail if anything changes anywhere).
>
> There are some reasons to sometimes depart from that rule, when things
> are too hard to check or too subtle to break. But just that this
> information can be deduced from some triplet in alone is no reason at
> all.

Another consideration is being able to do cross builds, and for that one
should avoid AC_TRY_RUN.

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Han-Wen Nienhuys]

Greg Troxel escreveu:
>> Just because something is part of some ABI is no reason to not try to
>> autodetect it. It's an elementary philisophical idea behind autoconf
>> (and one of its biggest advantages in my POV) that you do not check for
>> the system but for its features[1].
>> This allows it to support most new platforms for most programs out of
>> the box (and not fail if anything changes anywhere).
>>
>> There are some reasons to sometimes depart from that rule, when things
>> are too hard to check or too subtle to break. But just that this
>> information can be deduced from some triplet in alone is no reason at
>> all.
> 
> Another consideration is being able to do cross builds, and for that one
> should avoid AC_TRY_RUN.

Cross builds need a slew of overrides anyway. As long as the macro provides 
a way to override from the environment, cross-builds should not be a problem. 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Guile FTBFS on hppa - problem in detecting stack direction?

[Kyle McMartin]

On Thu, Aug 07, 2008 at 11:04:13PM +0200, Neil Jerram wrote:
> 2008/8/7 Carlos O'Donell <carlos@systemhalted.org>:
> > On Wed, Aug 6, 2008 at 4:38 PM, Neil Jerram <neiljerram@googlemail.com> wrote:
> >> SCM_I_GSC_STACK_GROWS_UP=0
> >
> > Move this line. [...]
> 
> > Tell me if that fixes your problem with cached variable detection.
> >
> > Cheers,
> > Carlos.
> 
> Many thanks.  I haven't tried it yet, but I expect you are right;
> sorry for making such a silly mistake!
> 

It happens, thanks for being so quick to get this sorted out!

cheers, Kyle