guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Greg Troxel]

guile 1.4 loses too.  I have an eerie feeling that I saw something
similar on an alpha long ago, but I never solved the problem.

The machine is an Ultra5, with NetBSD 1.6.2 and guile 1.6.4.

Any clues?  Is guile known to work on 64-bit machines?  ultrasparc?
With gcc 3.3.2?

gdt 119 /usr/pkgsrc/lang/guile > ldd /usr/pkg/bin/guile
/usr/pkg/bin/guile:
         -lcrypt.0 => /usr/lib/libcrypt.so.0
         -lm.0 => /usr/lib/libm.so.0
         -lguile-ltdl.1 => /usr/pkg/lib/libguile-ltdl.so.1
         -lguile.15 => /usr/pkg/lib/libguile.so.15
         -lc.12 => /usr/lib/libc.so.12

gdt 116 /usr/pkgsrc/lang/guile > cc -v
Reading specs from /usr/pkg/gcc3/lib/gcc-lib/sparc64--netbsd/3.3.2/specs
Configured with: ./configure --prefix=/usr/pkg/gcc3 --host=sparc64--netbsd --with-as=/usr/pkg/sparc64--netbsd/bin/as --enable-shared --enable-languages=c
Thread model: single
gcc version 3.3.2

gdt 118 /usr/pkgsrc/lang/guile > libtool --version
ltmain.sh (GNU libtool) 1.5.2 (1.1220.2.60 2004/01/25 12:25:08)

Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gdt 114 /usr/pkgsrc/lang/guile > gdb /usr/pkg/bin/guile
GNU gdb 5.0nb1
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc64--netbsd"...(no debugging symbols found)...
(gdb) run
Starting program: /usr/pkg/bin/guile 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x40203818 in _rtld_relocate_nonplt_object () from /usr/libexec/ld.elf_so
(gdb) bt
#0  0x40203818 in _rtld_relocate_nonplt_object () from /usr/libexec/ld.elf_so
#1  0x40204fd4 in _rtld_relocate_objects () from /usr/libexec/ld.elf_so
#2  0x4020477c in _rtld_dlopen () from /usr/libexec/ld.elf_so
#3  0x101138 in dlopen ()
#4  0x404da8fc in sys_dl_open () from /usr/pkg/lib/libguile-ltdl.so.1
#5  0x404db4d8 in tryall_dlopen () from /usr/pkg/lib/libguile-ltdl.so.1
#6  0x404dcb60 in try_dlopen () from /usr/pkg/lib/libguile-ltdl.so.1
#7  0x404dcfa0 in lt_dlopenext () from /usr/pkg/lib/libguile-ltdl.so.1
#8  0x404defd0 in scm_lt_dlopenext () from /usr/pkg/lib/libguile-ltdl.so.1
#9  0x40346d38 in sysdep_dynl_link () from /usr/pkg/lib/libguile.so.15
#10 0x40346fa0 in scm_dynamic_link () from /usr/pkg/lib/libguile.so.15
#11 0x40353844 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#12 0x40353f08 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#13 0x40355c58 in scm_i_eval_x () from /usr/pkg/lib/libguile.so.15
#14 0x40355d08 in scm_primitive_eval_x () from /usr/pkg/lib/libguile.so.15
#15 0x403722c0 in load () from /usr/pkg/lib/libguile.so.15
#16 0x4034771c in scm_internal_dynamic_wind () from /usr/pkg/lib/libguile.so.15
#17 0x403723f4 in scm_primitive_load () from /usr/pkg/lib/libguile.so.15
#18 0x40353844 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#19 0x40355098 in scm_apply () from /usr/pkg/lib/libguile.so.15
#20 0x403546e0 in scm_call_0 () from /usr/pkg/lib/libguile.so.15
#21 0x403475fc in scm_dynamic_wind () from /usr/pkg/lib/libguile.so.15
#22 0x40354004 in scm_ceval () from /usr/pkg/lib/libguile.so.15
---Type <return> to continue, or q <return> to quit---
#23 0x40351434 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#24 0x40355098 in scm_apply () from /usr/pkg/lib/libguile.so.15
#25 0x403546e0 in scm_call_0 () from /usr/pkg/lib/libguile.so.15
#26 0x403475fc in scm_dynamic_wind () from /usr/pkg/lib/libguile.so.15
#27 0x40354004 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#28 0x40351434 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#29 0x403520f8 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#30 0x40351434 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#31 0x40351ff8 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#32 0x40351ff8 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#33 0x40355098 in scm_apply () from /usr/pkg/lib/libguile.so.15
#34 0x40355608 in scm_for_each () from /usr/pkg/lib/libguile.so.15
#35 0x40354004 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#36 0x40355c58 in scm_i_eval_x () from /usr/pkg/lib/libguile.so.15
#37 0x40355d08 in scm_primitive_eval_x () from /usr/pkg/lib/libguile.so.15
#38 0x403722c0 in load () from /usr/pkg/lib/libguile.so.15
#39 0x4034771c in scm_internal_dynamic_wind () from /usr/pkg/lib/libguile.so.15
#40 0x403723f4 in scm_primitive_load () from /usr/pkg/lib/libguile.so.15
#41 0x40353844 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#42 0x40351384 in scm_ceval () from /usr/pkg/lib/libguile.so.15
#43 0x40355c58 in scm_i_eval_x () from /usr/pkg/lib/libguile.so.15
#44 0x40355d08 in scm_primitive_eval_x () from /usr/pkg/lib/libguile.so.15
#45 0x40355dac in inner_eval_x () from /usr/pkg/lib/libguile.so.15
---Type <return> to continue, or q <return> to quit---
#46 0x4034771c in scm_internal_dynamic_wind () from /usr/pkg/lib/libguile.so.15
#47 0x40355e4c in scm_eval_x () from /usr/pkg/lib/libguile.so.15
#48 0x4039091c in scm_shell () from /usr/pkg/lib/libguile.so.15
#49 0x101280 in dladdr ()
#50 0x4036f650 in invoke_main_func () from /usr/pkg/lib/libguile.so.15
#51 0x4036f600 in scm_boot_guile_1 () from /usr/pkg/lib/libguile.so.15
#52 0x4036f1cc in scm_boot_guile () from /usr/pkg/lib/libguile.so.15
#53 0x1012d8 in main ()
#54 0x101028 in ___start ()
(gdb) 




-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> guile 1.4 loses too.  I have an eerie feeling that I saw something
> similar on an alpha long ago, but I never solved the problem.
>
> The machine is an Ultra5, with NetBSD 1.6.2 and guile 1.6.4.
>
> Any clues?  Is guile known to work on 64-bit machines?  ultrasparc?
> With gcc 3.3.2?

I did some debugging a while back to fix some problems on the ia64 and
alpha, and I think it was working, but I may be mistaken.  Debian is
at least building/shipping it on 64-bit machines:
http://buildd.debian.org/build.php?arch=&pkg=guile-1.6, though I don't
know offhand which gcc it used for the most recent builds.  (Note to
self: I need to add "make check" to the debian build so we'll catch
problems earlier...)

If I couldn't easily see that you're using libguile-ltdl, I'd have
thought your libltdl was the problem.  Though it's of course possible
that we still have some bugs of our own in there.

Can you find out which dlopen it's failing on?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Greg Troxel]

  If I couldn't easily see that you're using libguile-ltdl, I'd have
  thought your libltdl was the problem.  Though it's of course possible
  that we still have some bugs of our own in there.

  Can you find out which dlopen it's failing on?

I built (from pkgsrc) and ran make check.
All worked except

ERROR: srfi-19.test: SRFI date/time library: #<procedure time-utc->date (time . tz-offset)> respects local DST if no TZ-OFFSET given - arguments: ((system-error "putenv" "~A" ("No such file or directory") (2)))

It's all coming back to me from running make check.  The problem was
the readline module.

gdt 39 /usr/pkgsrc/lang/guile > cd
sunpal5 gdt 40 ~ > guile -q
guile> (+ 2 3)
5
guile> (use-modules (ice-9 readline))
Segmentation fault (core dumped)

I have in my .guile:

; This file was automatically generated by m4.  DO NOT EDIT.
; Copyright (c) 1996,1997,1998,1999 Gregory D. Troxel.
; All rights reserved.
; Permission is granted to copy individual statements only if the
; the person copying the statement understands its functionality
; and agrees not to complain about their dotfiles at all while
; any code derived from this file is in them.
; This permission notice must be preserved on all copies and derived
; works.
(use-modules (ice-9 readline))
(define (ar)
  (activate-readline)
  )

and had forgotten - I think my alpha woes were at least 3 or 4 years
ago.  I can try to track this down more at some point.
Does readline work on your ia64 and alpha boxes?

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> and had forgotten - I think my alpha woes were at least 3 or 4 years
> ago.  I can try to track this down more at some point.  Does
> readline work on your ia64 and alpha boxes?

Hmm, seems to work on the ia64.  Just after a build and make install:

  $ uname -m
  ia64
  $ PATH=/home/rlb/opt/guile-1.6/bin:${PATH} LD_LIBRARY_PATH=/home/rlb/opt/guile-1.6/lib GUILE_LOAD_PATH=/home/rlb/opt/guile-1.6/share/guile/1.6 guile 
  guile> (use-modules (ice-9 readline))
  guile> (activate-readline)
  guile> 7
  7

and on an alpha:

  $ uname -m
  alpha
  $ PATH=/home/rlb/opt/guile-1.6/bin:${PATH} GUILE_LOAD_PATH=/home/rlb/opt/guile-1.6/share/guile/1.6 LD_LIBRARY_PATH=/home/rlb/opt/guile-1.6/lib guile
  guile> (use-modules (ice-9 readline))
  guile> (activate-readline)
  guile> 3
  3

In both cases, I used ./configure --enable-dynamic-linking
--prefix=/home/rlb/opt/guile-1.6.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Greg Troxel]

I did some more experiments.  It seems to be compiler dependent; with
gcc 2.95 it was ok, and with 3.3.2 sometimes (when compiled on some
machines) it segfaults and sometimes I get complaints about tputent
not being bound (and the program exits).  So my best guess at the
moment is that something is not right, but that it is ok in many
circumstances anyway.

-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> I did some more experiments.  It seems to be compiler dependent; with
> gcc 2.95 it was ok, and with 3.3.2 sometimes (when compiled on some
> machines) it segfaults and sometimes I get complaints about tputent
> not being bound (and the program exits).  So my best guess at the
> moment is that something is not right, but that it is ok in many
> circumstances anyway.

Here's something you might want to try, though it may not be related.
Modify your configure.in like this:

  ## If we're using GCC, ask for aggressive warnings.
  case "$GCC" in
    yes )
      ## We had -Wstrict-prototypes in here for a bit, but Guile does too
      ## much stuff with generic function pointers for that to really be
      ## less than exasperating.
      ## -Wpointer-arith was here too, but something changed in gcc/glibc
      ## and it became equally exasperating (gcc 2.95 and/or glibc 2.1.2).
      ## -fno-strict-aliasing keeps us from having to change our code for now.
      CFLAGS="$CFLAGS -Wall -Wmissing-prototypes -fno-strict-aliasing" ;;
  esac

and then re-autoconf and re-build.  Or, if you don't want to risk your
version of autoconf not being compatible, just edit your configure to
include -fno-strict-aliasing where it now only has -Wall -Wmissing...,
etc.  I've modified current 1.6 CVS to include this, and it's
something we need for now regardless, but your copy doesn't have it.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
>       ## -fno-strict-aliasing keeps us from having to change our code for now.

What sorts of changes would be needed to make -fno-strict-aliasing
unnecessary?


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> What sorts of changes would be needed to make -fno-strict-aliasing
> unnecessary?

Not sure offhand.  We're not likely worry about that in 1.6, but we
probably will in 1.7.  In general gcc will warn you about some of the
problems, but I'd presume that it can't detect all of them.

You may already be familiar with the general issue, but in case not,
the change is that gcc now follows the C standard more strictly by
default when optimizing, and so (if I have this right off the top of
my head) it's no longer safe to access data through any pointer that's
not of a type that's "compatible" with the type of the actual data,
i.e. given

  double x = 5;
  double *dptr = &x;
  int *iptr = (int *) &x;

  *iptr = 12;
  *dptr = 42;
  foo(x);

I believe the compiler is now within its rights to generate code that
re-orders the iptr and dptr assignments, leaving x with some value
other than 42 by the time foo is called.

That's because the optimizer is legally allowed to presume that
incompatible pointers do not alias the same memory locations, even if
they do.  Although I believe char* is at least one (maybe the only)
exception to this; according to the standard a char* must be presumed
to alias any location. Also, I think you may be able to use a union
safely as an alternative with gcc, but from what I recall, that's
non-standard.

With respect to guile, I'm not sure what, if anything, needs fixing in
1.7, but we'll need to check into it before we disable
-fno-strict-aliasing.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

aliasing (was: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2)

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> Also, I think you may be able to use a union safely as an
> alternative with gcc, but from what I recall, that's non-standard.

I don't think it's generally possible for gcc to handle that case
specially.  Consider:

void foo(int* i, float* f) { *i=42; *f=3.14159; }

void bar(void) {
  union { int i; float f; } u;
  foo(&u.i, &u.f);
  /* What's in u.f now? */
}

These functions could appear in different source files.  So when foo
is being compiled, the compiler can't know whether i and f point to
overlapping members of the same union.  It assumes they don't overlap
because of their types, and reorders the writes if it likes.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel