unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#45214: guile segfaults on 32-bit big-endian targets
@ 2020-12-12 21:26 John Paul Adrian Glaubitz
  2020-12-12 22:00 ` John David Anglin
  2020-12-12 22:21 ` John David Anglin
  0 siblings, 2 replies; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2020-12-12 21:26 UTC (permalink / raw)
  To: 45214; +Cc: Helge Deller, John David Anglin, Andreas Schwab, Michael Karcher

Hello!

As reported in [1], guile segfaults on 32-bit big-endian targets with:

guild compile --target="hppa-unknown-linux-gnu"                \
          -W0 -O1              \
  -L "/<<PKGBUILDDIR>>/module"                         \
  -L "/<<PKGBUILDDIR>>/guile-readline"			\
  -o "language/tree-il/eta-expand.go" "../module/language/tree-il/eta-expand.scm"
make[4]: *** [Makefile:1927: language/tree-il/eta-expand.go] Segmentation fault
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [Makefile:1927: language/tree-il/debug.go] Segmentation fault
make[4]: *** [Makefile:1927: language/tree-il/analyze.go] Segmentation fault
still going
make[4]: *** [Makefile:1927: language/tree-il/effects.go] Segmentation fault
make[4]: Leaving directory '/<<PKGBUILDDIR>>/bootstrap'
make[3]: *** [Makefile:1851: all-recursive] Error 1
make[3]: Leaving directory '/<<PKGBUILDDIR>>'
make[2]: *** [Makefile:1737: all] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>'
make[1]: *** [debian/rules:192: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:104: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2

Full build log in [2]. This affects hppa, m68k and powerpc (32-bit).

Backtrace:

#0  0x006e3e9c in scm_sum (x=x@entry=0x0, y=0x6) at numbers.c:7569
7569      else if (SCM_BIGP (x))
[Current thread is 1 (Thread 0xf7c34480 (LWP 529732))]
(gdb) bt
#0  0x006e3e9c in scm_sum (x=x@entry=0x0, y=0x6) at numbers.c:7569
#1  0x006cd498 in add_immediate (a=0x0, b=<optimized out>) at intrinsics.c:80
#2  0x00749818 in vm_regular_engine (thread=0xf7971e00) at vm-engine.c:1583
#3  0x0074c2f4 in scm_call_n (proc=proc@entry=0xeffbf148, argv=argv@entry=0x0, 
nargs=nargs@entry=0) at vm.c:1608
#4  0x006a70fc in scm_call_0 (proc=proc@entry=0xeffbf148) at eval.c:490
#5  0x006d39d8 in scm_primitive_load_path (args=<optimized out>) at load.c:1259
#6  0x006d3f28 in scm_c_primitive_load_path (filename=filename@entry=0x776458 
"ice-9/boot-9") at load.c:1275
#7  0x006c9310 in scm_load_startup_files () at init.c:222
#8  0x006c96a8 in scm_i_init_guile (base=base@entry=0xffecfb18) at init.c:505
#9  0x0073b858 in scm_i_init_thread_for_guile (base=base@entry=0xffecfb18, 
dynamic_state=dynamic_state@entry=0x0) at threads.c:570
#10 0x0073ba1c in scm_i_init_thread_for_guile (dynamic_state=0x0, 
base=0xffecfb18) at threads.c:677
#11 with_guile (base=0xffecfb18, data=0xffecfb38) at threads.c:638
#12 0x003e17e4 in GC_call_with_stack_base () from 
/usr/lib/powerpc-linux-gnu/libgc.so.1
#13 0x0073bfb8 in scm_i_with_guile (dynamic_state=<optimized out>, 
data=0xffecfb28, func=0x6c90c0 <invoke_main_func>) at threads.c:688
#14 scm_with_guile (func=func@entry=0x6c90c0 <invoke_main_func>, 
data=data@entry=0xffecfb58) at threads.c:694
#15 0x006c93c8 in scm_boot_guile (argc=argc@entry=16, 
argv=argv@entry=0xffecfe14, main_func=main_func@entry=0x800950 <inner_main>, 
closure=closure@entry=0x0) at init.c:290
#16 0x00800754 in main (argc=16, argv=0xffecfe14) at guile.c:95
(gdb)

I assume the crash has got something to do how values are packed and unpacked
into the SCM object type. I have not been able to find the problem yet myself,
unfortunately which is why I am reporting this issue here.

For anyone willing to debug this, access to a fast POWER machine running a
big-endian Debian unstable can be obtained through the GCC compile farm [3].

Thanks,
Adrian

> [1] https://lists.gnu.org/archive/html/guile-devel/2020-12/msg00003.html
> [2] https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=hppa&ver=3.0.4-3&stamp=1607546304&raw=0
> [3] https://gcc.gnu.org/wiki/CompileFarm

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 21:26 bug#45214: guile segfaults on 32-bit big-endian targets John Paul Adrian Glaubitz
@ 2020-12-12 22:00 ` John David Anglin
  2020-12-12 22:02   ` John Paul Adrian Glaubitz
  2020-12-12 22:21 ` John David Anglin
  1 sibling, 1 reply; 20+ messages in thread
From: John David Anglin @ 2020-12-12 22:00 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

Hi,

I created this debian PR earlier today:
Bug#977223: Acknowledgement (guile-3.0: FTBFS on hppa - segmentation faults)

In the above, the segmentation fault occurs during exception handling on hppa.  The exception is more
or less handled on powerpc:

../meta/build-env                \
guild compile --target="powerpc-unknown-linux-gnu"                \
          -W0 -O1              \
  -L "/<<PKGBUILDDIR>>/module"                         \
  -L "/<<PKGBUILDDIR>>/guile-readline"            \
  -o "language/tree-il/compile-cps.go" "../module/language/tree-il/compile-cps.scm"
Backtrace:
          11 (_ #<procedure efa84650 at ice-9/eval.scm:330:13 ()> # #)
          10 (apply-smob/0 #<thunk efa7cba0>)
In ice-9/eval.scm:
    657:8  9 (_ #(#(#f) ("prompt") #<procedure efacfcb0 at ice-9/?> ?))
    619:8  8 (_ #(#(#<directory (guile-user) f00566e0>)))
    155:9  7 (_ #(#(#<directory (guild) efe0daa0> ("compile" # ?)) #))
    619:8  6 (_ #(#(#<directory (srfi srfi-1) efcc4780> #<proc?> ?) ?))
    163:9  5 (_ #(#(#<directory (scripts compile) ef13ae60> "p?" ?) ?))
In unknown file:
           4 (_ #<procedure eebf7cb0 at ice-9/eval.scm:330:13 ()> # #)
In system/base/target.scm:
     65:6  3 (with-target "powerpc-unknown-linux-gnu" #<procedure ee?>)
In system/base/compile.scm:
    187:6  2 (compile-file "../module/ice-9/rdelim.scm" #:output-file ?)
    56:12  1 (call-once #<procedure ee49af40 at system/base/compile.?>)
In unknown file:
           0 (_ #<procedure ee413dc0 at ice-9/eval.scm:330:13 ()> # #)

ERROR: thunk may only be entered once: ~a #<procedure ee49af40 at system/base/compile.scm:66:5 ()>
make[4]: *** [Makefile:1927: ice-9/rdelim.go] Error 1

Trying to bisect.

Regards,
Dave

On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
> Hello!
>
> As reported in [1], guile segfaults on 32-bit big-endian targets with:
>
> guild compile --target="hppa-unknown-linux-gnu"                \
>           -W0 -O1              \
>   -L "/<<PKGBUILDDIR>>/module"                         \
>   -L "/<<PKGBUILDDIR>>/guile-readline"			\
>   -o "language/tree-il/eta-expand.go" "../module/language/tree-il/eta-expand.scm"
> make[4]: *** [Makefile:1927: language/tree-il/eta-expand.go] Segmentation fault
> make[4]: *** Waiting for unfinished jobs....
> make[4]: *** [Makefile:1927: language/tree-il/debug.go] Segmentation fault
> make[4]: *** [Makefile:1927: language/tree-il/analyze.go] Segmentation fault
> still going
> make[4]: *** [Makefile:1927: language/tree-il/effects.go] Segmentation fault
> make[4]: Leaving directory '/<<PKGBUILDDIR>>/bootstrap'
> make[3]: *** [Makefile:1851: all-recursive] Error 1
> make[3]: Leaving directory '/<<PKGBUILDDIR>>'
> make[2]: *** [Makefile:1737: all] Error 2
> make[2]: Leaving directory '/<<PKGBUILDDIR>>'
> make[1]: *** [debian/rules:192: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> make: *** [debian/rules:104: build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
>
> Full build log in [2]. This affects hppa, m68k and powerpc (32-bit).
>
> Backtrace:
>
> #0  0x006e3e9c in scm_sum (x=x@entry=0x0, y=0x6) at numbers.c:7569
> 7569      else if (SCM_BIGP (x))
> [Current thread is 1 (Thread 0xf7c34480 (LWP 529732))]
> (gdb) bt
> #0  0x006e3e9c in scm_sum (x=x@entry=0x0, y=0x6) at numbers.c:7569
> #1  0x006cd498 in add_immediate (a=0x0, b=<optimized out>) at intrinsics.c:80
> #2  0x00749818 in vm_regular_engine (thread=0xf7971e00) at vm-engine.c:1583
> #3  0x0074c2f4 in scm_call_n (proc=proc@entry=0xeffbf148, argv=argv@entry=0x0, 
> nargs=nargs@entry=0) at vm.c:1608
> #4  0x006a70fc in scm_call_0 (proc=proc@entry=0xeffbf148) at eval.c:490
> #5  0x006d39d8 in scm_primitive_load_path (args=<optimized out>) at load.c:1259
> #6  0x006d3f28 in scm_c_primitive_load_path (filename=filename@entry=0x776458 
> "ice-9/boot-9") at load.c:1275
> #7  0x006c9310 in scm_load_startup_files () at init.c:222
> #8  0x006c96a8 in scm_i_init_guile (base=base@entry=0xffecfb18) at init.c:505
> #9  0x0073b858 in scm_i_init_thread_for_guile (base=base@entry=0xffecfb18, 
> dynamic_state=dynamic_state@entry=0x0) at threads.c:570
> #10 0x0073ba1c in scm_i_init_thread_for_guile (dynamic_state=0x0, 
> base=0xffecfb18) at threads.c:677
> #11 with_guile (base=0xffecfb18, data=0xffecfb38) at threads.c:638
> #12 0x003e17e4 in GC_call_with_stack_base () from 
> /usr/lib/powerpc-linux-gnu/libgc.so.1
> #13 0x0073bfb8 in scm_i_with_guile (dynamic_state=<optimized out>, 
> data=0xffecfb28, func=0x6c90c0 <invoke_main_func>) at threads.c:688
> #14 scm_with_guile (func=func@entry=0x6c90c0 <invoke_main_func>, 
> data=data@entry=0xffecfb58) at threads.c:694
> #15 0x006c93c8 in scm_boot_guile (argc=argc@entry=16, 
> argv=argv@entry=0xffecfe14, main_func=main_func@entry=0x800950 <inner_main>, 
> closure=closure@entry=0x0) at init.c:290
> #16 0x00800754 in main (argc=16, argv=0xffecfe14) at guile.c:95
> (gdb)
>
> I assume the crash has got something to do how values are packed and unpacked
> into the SCM object type. I have not been able to find the problem yet myself,
> unfortunately which is why I am reporting this issue here.
>
> For anyone willing to debug this, access to a fast POWER machine running a
> big-endian Debian unstable can be obtained through the GCC compile farm [3].
>
> Thanks,
> Adrian
>
>> [1] https://lists.gnu.org/archive/html/guile-devel/2020-12/msg00003.html
>> [2] https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=hppa&ver=3.0.4-3&stamp=1607546304&raw=0
>> [3] https://gcc.gnu.org/wiki/CompileFarm


-- 
John David Anglin  dave.anglin@bell.net







^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:00 ` John David Anglin
@ 2020-12-12 22:02   ` John Paul Adrian Glaubitz
  2021-02-25 15:24     ` Efraim Flashner
  0 siblings, 1 reply; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2020-12-12 22:02 UTC (permalink / raw)
  To: dave.anglin, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

Hi!

On 12/12/20 11:00 PM, John David Anglin wrote:
> Trying to bisect.

Bisecting lead me to this which I guess is just painting over the real
problem:

(sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$ git bisect good
a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0 is the first bad commit
commit a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0
Author: Andy Wingo <wingo@pobox.com>
Date:   Mon May 11 15:22:29 2020 +0200

    Switch to baseline compiler for bootstrap/

    * bootstrap/Makefile.am (GUILE_OPTIMIZATIONS): Add -Ono-cps so that we
      use the baseline compiler when bootstrapping.

 bootstrap/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 21:26 bug#45214: guile segfaults on 32-bit big-endian targets John Paul Adrian Glaubitz
  2020-12-12 22:00 ` John David Anglin
@ 2020-12-12 22:21 ` John David Anglin
  2020-12-12 22:30   ` John David Anglin
  2021-02-08 23:24   ` John David Anglin
  1 sibling, 2 replies; 20+ messages in thread
From: John David Anglin @ 2020-12-12 22:21 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
> I assume the crash has got something to do how values are packed and unpacked
> into the SCM object type. I have not been able to find the problem yet myself,
> unfortunately which is why I am reporting this issue here.
I see this in scm.h:

/* The 0?: constructions makes sure that the code is never executed, and
   that there is no performance hit.  However, the alternative is
   compiled, and does generate a warning when used with the wrong
   pointer type.  We use a volatile pointer type to avoid warnings from
   clang.

   The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
   statements, so for them type-checking is disabled.  */
# if defined __DECC || defined __HP_cc
#  define SCM_UNPACK(x) ((scm_t_bits) (x))
# else
#  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
# endif

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:21 ` John David Anglin
@ 2020-12-12 22:30   ` John David Anglin
  2020-12-12 22:44     ` John David Anglin
  2021-02-08 23:24   ` John David Anglin
  1 sibling, 1 reply; 20+ messages in thread
From: John David Anglin @ 2020-12-12 22:30 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 2020-12-12 5:21 p.m., John David Anglin wrote:
> On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
>> I assume the crash has got something to do how values are packed and unpacked
>> into the SCM object type. I have not been able to find the problem yet myself,
>> unfortunately which is why I am reporting this issue here.
> I see this in scm.h:
>
> /* The 0?: constructions makes sure that the code is never executed, and
>    that there is no performance hit.  However, the alternative is
>    compiled, and does generate a warning when used with the wrong
>    pointer type.  We use a volatile pointer type to avoid warnings from
>    clang.
>
>    The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
>    statements, so for them type-checking is disabled.  */
> # if defined __DECC || defined __HP_cc
> #  define SCM_UNPACK(x) ((scm_t_bits) (x))
> # else
> #  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
> # endif
Also just before, there is:
/* But as external interface, we define SCM, which may, according to the
   desired level of type checking, be defined in several ways.  */
#if (SCM_DEBUG_TYPING_STRICTNESS == 2)
  typedef union SCM { struct { scm_t_bits n; } n; } SCM;
# define SCM_UNPACK(x) ((x).n.n)
# define SCM_PACK(x) ((SCM) { { (scm_t_bits) (x) } })
#elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
/* This is the default, which provides an intermediate level of compile
   time type checking while still resulting in very efficient code.  */
  typedef struct scm_unused_struct { char scm_unused_field; } *SCM;

The fault on hppa appears to be at strictness 1.

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:30   ` John David Anglin
@ 2020-12-12 22:44     ` John David Anglin
  2020-12-12 22:47       ` John Paul Adrian Glaubitz
  0 siblings, 1 reply; 20+ messages in thread
From: John David Anglin @ 2020-12-12 22:44 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 2020-12-12 5:30 p.m., John David Anglin wrote:
> On 2020-12-12 5:21 p.m., John David Anglin wrote:
>> On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
>>> I assume the crash has got something to do how values are packed and unpacked
>>> into the SCM object type. I have not been able to find the problem yet myself,
>>> unfortunately which is why I am reporting this issue here.
>> I see this in scm.h:
>>
>> /* The 0?: constructions makes sure that the code is never executed, and
>>    that there is no performance hit.  However, the alternative is
>>    compiled, and does generate a warning when used with the wrong
>>    pointer type.  We use a volatile pointer type to avoid warnings from
>>    clang.
>>
>>    The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
>>    statements, so for them type-checking is disabled.  */
>> # if defined __DECC || defined __HP_cc
>> #  define SCM_UNPACK(x) ((scm_t_bits) (x))
>> # else
>> #  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
>> # endif
> Also just before, there is:
> /* But as external interface, we define SCM, which may, according to the
>    desired level of type checking, be defined in several ways.  */
> #if (SCM_DEBUG_TYPING_STRICTNESS == 2)
>   typedef union SCM { struct { scm_t_bits n; } n; } SCM;
> # define SCM_UNPACK(x) ((x).n.n)
> # define SCM_PACK(x) ((SCM) { { (scm_t_bits) (x) } })
> #elif (SCM_DEBUG_TYPING_STRICTNESS == 1)
> /* This is the default, which provides an intermediate level of compile
>    time type checking while still resulting in very efficient code.  */
>   typedef struct scm_unused_struct { char scm_unused_field; } *SCM;
>
> The fault on hppa appears to be at strictness 1.
Guess, I should have copied the whole bit:

The last option is:
#else
/* This should be used as a fall back solution for machines on which
   casting to a pointer may lead to loss of bit information, e. g. in
   the three least significant bits.  */
  typedef scm_t_bits SCM;
# define SCM_UNPACK(x) (x)
# define SCM_PACK(x) ((SCM) (x))
#endif

I think strictness 1 may be problematic on hppa.

Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:44     ` John David Anglin
@ 2020-12-12 22:47       ` John Paul Adrian Glaubitz
  2020-12-12 23:22         ` John David Anglin
  2020-12-13 18:06         ` John David Anglin
  0 siblings, 2 replies; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2020-12-12 22:47 UTC (permalink / raw)
  To: dave.anglin, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 12/12/20 11:44 PM, John David Anglin wrote:
> Guess, I should have copied the whole bit:
> 
> The last option is:
> #else
> /* This should be used as a fall back solution for machines on which
>    casting to a pointer may lead to loss of bit information, e. g. in
>    the three least significant bits.  */
>   typedef scm_t_bits SCM;
> # define SCM_UNPACK(x) (x)
> # define SCM_PACK(x) ((SCM) (x))
> #endif
> 
> I think strictness 1 may be problematic on hppa.

And m68k and powerpc most likely.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:47       ` John Paul Adrian Glaubitz
@ 2020-12-12 23:22         ` John David Anglin
  2020-12-13 18:06         ` John David Anglin
  1 sibling, 0 replies; 20+ messages in thread
From: John David Anglin @ 2020-12-12 23:22 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 2020-12-12 5:47 p.m., John Paul Adrian Glaubitz wrote:
> And m68k and powerpc most likely.
This could also be a bug on 32-bit targets:
  CC       libguile_3.0_la-hash.lo
../../guile/libguile/hash.c: In function 'narrow_string_hash':
../../guile/libguile/hash.c:118:34: warning: left shift count >= width of type [
-Wshift-count-overflow]
  118 |       ret = (((unsigned long) c) << 32) | b;
\
      |                                  ^~
../../guile/libguile/hash.c:128:3: note: in expansion of macro 'JENKINS_LOOKUP3_
HASHWORD2'
  128 |   JENKINS_LOOKUP3_HASHWORD2 (str, len, ret);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~
../../guile/libguile/hash.c: In function 'wide_string_hash':
../../guile/libguile/hash.c:118:34: warning: left shift count >= width of type [-Wshift-count-overflow]
  118 |       ret = (((unsigned long) c) << 32) | b;                            \
      |                                  ^~

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:47       ` John Paul Adrian Glaubitz
  2020-12-12 23:22         ` John David Anglin
@ 2020-12-13 18:06         ` John David Anglin
  2020-12-13 18:08           ` John Paul Adrian Glaubitz
  1 sibling, 1 reply; 20+ messages in thread
From: John David Anglin @ 2020-12-13 18:06 UTC (permalink / raw)
  To: glaubitz, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 2020-12-12 5:47 p.m., John Paul Adrian Glaubitz wrote:
>> I think strictness 1 may be problematic on hppa.
> And m68k and powerpc most likely.
I did a build of the current debian package on hppa with type strictness set to 0.  With that, I get the same fault
that you reported for powerpc.   SCM_BIGP(x) faults when x is 0.

I updated debian PR with additional analysis:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net







^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-13 18:06         ` John David Anglin
@ 2020-12-13 18:08           ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2020-12-13 18:08 UTC (permalink / raw)
  To: dave.anglin, 45214; +Cc: Helge Deller, Michael Karcher, Andreas Schwab

On 12/13/20 7:06 PM, John David Anglin wrote:
> I did a build of the current debian package on hppa with type strictness set to 0.  With that, I get the same fault
> that you reported for powerpc.   SCM_BIGP(x) faults when x is 0.
> 
> I updated debian PR with additional analysis:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223

See also: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:21 ` John David Anglin
  2020-12-12 22:30   ` John David Anglin
@ 2021-02-08 23:24   ` John David Anglin
  2021-02-09 13:03     ` John David Anglin
  1 sibling, 1 reply; 20+ messages in thread
From: John David Anglin @ 2021-02-08 23:24 UTC (permalink / raw)
  To: glaubitz, 45214

On 2020-12-12 5:21 p.m., John David Anglin wrote:
> On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
>> I assume the crash has got something to do how values are packed and unpacked
>> into the SCM object type. I have not been able to find the problem yet myself,
>> unfortunately which is why I am reporting this issue here.
> I see this in scm.h:
>
> /* The 0?: constructions makes sure that the code is never executed, and
>    that there is no performance hit.  However, the alternative is
>    compiled, and does generate a warning when used with the wrong
>    pointer type.  We use a volatile pointer type to avoid warnings from
>    clang.
>
>    The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
>    statements, so for them type-checking is disabled.  */
> # if defined __DECC || defined __HP_cc
> #  define SCM_UNPACK(x) ((scm_t_bits) (x))
> # else
> #  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
> # endif
I don't believe this is a problem.

We need to investigate why scm_sum is passed "x=x@entry=0x0".   SCM_BIGP (x) will fault on it.   Maybe SP_REF is broken.

Regards,
Dave

-- 
John David Anglin  dave.anglin@bell.net







^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-02-08 23:24   ` John David Anglin
@ 2021-02-09 13:03     ` John David Anglin
  0 siblings, 0 replies; 20+ messages in thread
From: John David Anglin @ 2021-02-09 13:03 UTC (permalink / raw)
  To: glaubitz, 45214

On 2021-02-08 6:24 p.m., John David Anglin wrote:
> We need to investigate why scm_sum is passed "x=x@entry=0x0".   SCM_BIGP (x) will fault on it.   Maybe SP_REF is broken.
To be more specific, this is the type of sp:

(gdb) ptype sp
type = union scm_vm_stack_element {
    uintptr_t as_uint;
    uint32_t *as_vcode;
    uint8_t *as_mcode;
    SCM as_scm;
    double as_f64;
    uint64_t as_u64;
    int64_t as_s64;
    void *as_ptr;
    scm_t_bits as_bits;
} *
(gdb) p/x &((union scm_vm_stack_element *)$r26)[0].as_scm
$11 = 0xf34147f0
(gdb) p/x &((union scm_vm_stack_element *)$r26)[1].as_scm
$12 = 0xf34147f8
(gdb) x/x 0xf34147f0
0xf34147f0:     0x00000001
(gdb) x/x 0xf34147f8
0xf34147f8:     0x0090020d
(gdb) p/x ((union scm_vm_stack_element *)$r26)[1].as_scm
$13 = 0x90020d
(gdb) p/x ((union scm_vm_stack_element *)$r26)[0].as_scm
$14 = 0x1
(gdb) x/8x 0xf34147f0
0xf34147f0:     0x00000001      0x00002c56      0x0090020d      0x0000097c
0xf3414800:     0x00000007      0x00000c83      0x0000097d      0x000d007f

There are endian aspects to consider in accessing the scm_vm_stack_element struct.

Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2020-12-12 22:02   ` John Paul Adrian Glaubitz
@ 2021-02-25 15:24     ` Efraim Flashner
  2021-04-14 14:18       ` Efraim Flashner
  0 siblings, 1 reply; 20+ messages in thread
From: Efraim Flashner @ 2021-02-25 15:24 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: deller, dave.anglin, schwab, 45214, debian

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

On Sat, Dec 12, 2020 at 11:02:47PM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 12/12/20 11:00 PM, John David Anglin wrote:
> > Trying to bisect.
> 
> Bisecting lead me to this which I guess is just painting over the real
> problem:
> 
> (sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$ git bisect good
> a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0 is the first bad commit
> commit a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0
> Author: Andy Wingo <wingo@pobox.com>
> Date:   Mon May 11 15:22:29 2020 +0200
> 
>     Switch to baseline compiler for bootstrap/
> 
>     * bootstrap/Makefile.am (GUILE_OPTIMIZATIONS): Add -Ono-cps so that we
>       use the baseline compiler when bootstrapping.
> 
>  bootstrap/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> (sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$
> 

I came to the same conclusion when I tried to bisect the git repo
between 3.0.2 and 3.0.3 on my powerpc machine. By reverting that commit
I was able to build 44ad8fbde55df452ac1c88427662403e7af5b9bb (3.0.2-70,
6 commit later) but wasn't able to build 3.0.3. I started the build
without any precompiled bootstrap .go files.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-02-25 15:24     ` Efraim Flashner
@ 2021-04-14 14:18       ` Efraim Flashner
  2021-04-14 19:19         ` John Paul Adrian Glaubitz
  2021-10-03  9:38         ` John Paul Adrian Glaubitz
  0 siblings, 2 replies; 20+ messages in thread
From: Efraim Flashner @ 2021-04-14 14:18 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: deller, dave.anglin, schwab, 45214, debian


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

On Thu, Feb 25, 2021 at 05:24:04PM +0200, Efraim Flashner wrote:
> On Sat, Dec 12, 2020 at 11:02:47PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi!
> > 
> > On 12/12/20 11:00 PM, John David Anglin wrote:
> > > Trying to bisect.
> > 
> > Bisecting lead me to this which I guess is just painting over the real
> > problem:
> > 
> > (sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$ git bisect good
> > a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0 is the first bad commit
> > commit a68c80c747a2a8ec92fa84684ebd60b4ecb7ffa0
> > Author: Andy Wingo <wingo@pobox.com>
> > Date:   Mon May 11 15:22:29 2020 +0200
> > 
> >     Switch to baseline compiler for bootstrap/
> > 
> >     * bootstrap/Makefile.am (GUILE_OPTIMIZATIONS): Add -Ono-cps so that we
> >       use the baseline compiler when bootstrapping.
> > 
> >  bootstrap/Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > (sid_powerpc-dchroot)glaubitz@perotto:~/guile-git$
> > 
> 
> I came to the same conclusion when I tried to bisect the git repo
> between 3.0.2 and 3.0.3 on my powerpc machine. By reverting that commit
> I was able to build 44ad8fbde55df452ac1c88427662403e7af5b9bb (3.0.2-70,
> 6 commit later) but wasn't able to build 3.0.3. I started the build
> without any precompiled bootstrap .go files.
> 

I spent some more time bisecting guile so I could create a diff against
3.0.5 and then spent another two weeks or so bootstrapping Guix from my
custom bootstrap binaries out to mesa.

I've attached the patch that's likely to go into Guix to add powerpc
support. Other than the mysterious failing test I've changed the
GUILE_OPTIMIZATIONS in bootstrap/Makefile.in to '-O1
-Oresolve-primitives -Ocps' on powerpc and it seems to be working fine.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: 0002-gnu-guile-3.0-Fix-building-on-powerpc-linux.patch --]
[-- Type: text/plain, Size: 2374 bytes --]

From c11ad7faa3690b2dfef924a31137f6ced5aab23f Mon Sep 17 00:00:00 2001
Message-Id: <c11ad7faa3690b2dfef924a31137f6ced5aab23f.1617711307.git.efraim@flashner.co.il>
In-Reply-To: <cover.1617711307.git.efraim@flashner.co.il>
References: <cover.1617711307.git.efraim@flashner.co.il>
From: Efraim Flashner <efraim@flashner.co.il>
Date: Mon, 8 Mar 2021 22:13:56 +0200
Subject: [PATCH 2/9] gnu: guile-3.0: Fix building on powerpc-linux.

* gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
phases to adjust for 32-bit big-endian systems.
---
 gnu/packages/guile.scm | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index f63322794d..dca1b1c16f 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -305,7 +305,26 @@ without requiring the source code to be rewritten.")
          (substitute-keyword-arguments (package-arguments guile-2.2)
            ((#:configure-flags flags ''())
             `(cons "--disable-jit" ,flags)))
-         (package-arguments guile-2.2)))
+         (if (string-prefix? "powerpc-" (%current-system))
+           (substitute-keyword-arguments (package-arguments guile-2.2)
+             ((#:phases phases)
+              `(modify-phases ,phases
+                 (add-after 'unpack 'adjust-bootstrap-flags
+                   (lambda _
+                     ;; Upstream not yet notified about suggested solution.
+                     ;; See existing bug reports:
+                     ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214
+                     ;; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223
+                     (substitute* "bootstrap/Makefile.in"
+                       (("^GUILE_OPTIMIZATIONS.*")
+                        "GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives -Ocps\n"))
+                     #t))
+                 (add-after 'unpack 'remove-failing-tests
+                   (lambda _
+                     ;; TODO: Discover why this test fails on powerpc-linux
+                     (delete-file "test-suite/standalone/test-out-of-memory")
+                     #t)))))
+           (package-arguments guile-2.2))))
     (native-search-paths
      (list (search-path-specification
             (variable "GUILE_LOAD_PATH")
-- 
2.31.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-04-14 14:18       ` Efraim Flashner
@ 2021-04-14 19:19         ` John Paul Adrian Glaubitz
  2021-04-15 11:50           ` Efraim Flashner
  2021-10-03  9:38         ` John Paul Adrian Glaubitz
  1 sibling, 1 reply; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-14 19:19 UTC (permalink / raw)
  To: efraim, 45214, deller, dave.anglin, schwab, debian

Hi1

On 4/14/21 4:18 PM, Efraim Flashner wrote:
> I spent some more time bisecting guile so I could create a diff against
> 3.0.5 and then spent another two weeks or so bootstrapping Guix from my
> custom bootstrap binaries out to mesa.
> 
> I've attached the patch that's likely to go into Guix to add powerpc
> support. Other than the mysterious failing test I've changed the
> GUILE_OPTIMIZATIONS in bootstrap/Makefile.in to '-O1
> -Oresolve-primitives -Ocps' on powerpc and it seems to be working fine.

Since this issue affects all 32-bit big-endian targets (hppa, m68k, ppc),
we should consider extending your patch to consider all these targets,
shouldn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-04-14 19:19         ` John Paul Adrian Glaubitz
@ 2021-04-15 11:50           ` Efraim Flashner
  2021-04-15 13:23             ` John Paul Adrian Glaubitz
  0 siblings, 1 reply; 20+ messages in thread
From: Efraim Flashner @ 2021-04-15 11:50 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: deller, dave.anglin, schwab, 45214, debian

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

On Wed, Apr 14, 2021 at 09:19:51PM +0200, John Paul Adrian Glaubitz wrote:
> Hi1
> 
> On 4/14/21 4:18 PM, Efraim Flashner wrote:
> > I spent some more time bisecting guile so I could create a diff against
> > 3.0.5 and then spent another two weeks or so bootstrapping Guix from my
> > custom bootstrap binaries out to mesa.
> > 
> > I've attached the patch that's likely to go into Guix to add powerpc
> > support. Other than the mysterious failing test I've changed the
> > GUILE_OPTIMIZATIONS in bootstrap/Makefile.in to '-O1
> > -Oresolve-primitives -Ocps' on powerpc and it seems to be working fine.
> 
> Since this issue affects all 32-bit big-endian targets (hppa, m68k, ppc),
> we should consider extending your patch to consider all these targets,
> shouldn't we?
> 

Guix doesn't target those platforms so it's not something that I've had
the chance to test yet.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-04-15 11:50           ` Efraim Flashner
@ 2021-04-15 13:23             ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-04-15 13:23 UTC (permalink / raw)
  To: efraim, 45214, deller, dave.anglin, schwab, debian

On 4/15/21 1:50 PM, Efraim Flashner wrote:
>> Since this issue affects all 32-bit big-endian targets (hppa, m68k, ppc),
>> we should consider extending your patch to consider all these targets,
>> shouldn't we?
>>
> 
> Guix doesn't target those platforms so it's not something that I've had
> the chance to test yet.

OK, I'll try a modified version of your patch on Debian and see if it helps.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-04-14 14:18       ` Efraim Flashner
  2021-04-14 19:19         ` John Paul Adrian Glaubitz
@ 2021-10-03  9:38         ` John Paul Adrian Glaubitz
  2021-10-04 16:08           ` John David Anglin
  1 sibling, 1 reply; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-10-03  9:38 UTC (permalink / raw)
  To: efraim, 45214, deller, dave.anglin, schwab, debian

Hi Efraim!

On 4/14/21 16:18, Efraim Flashner wrote:
> I spent some more time bisecting guile so I could create a diff against
> 3.0.5 and then spent another two weeks or so bootstrapping Guix from my
> custom bootstrap binaries out to mesa.
> 
> I've attached the patch that's likely to go into Guix to add powerpc
> support. Other than the mysterious failing test I've changed the
> GUILE_OPTIMIZATIONS in bootstrap/Makefile.in to '-O1
> -Oresolve-primitives -Ocps' on powerpc and it seems to be working fine.

I can confirm that adding "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS
in bootstrap/Makefile.am fixes the problem for me on 32-bit PowerPC on Debian.

I will have to figure out how to add "-Oresolve-primitives -Ocps" on 32-bit
big-endian conditionally so that it is not passed for other architectures.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-10-03  9:38         ` John Paul Adrian Glaubitz
@ 2021-10-04 16:08           ` John David Anglin
  2021-10-04 16:11             ` John Paul Adrian Glaubitz
  0 siblings, 1 reply; 20+ messages in thread
From: John David Anglin @ 2021-10-04 16:08 UTC (permalink / raw)
  To: glaubitz, efraim, 45214, deller, schwab, debian

On 2021-10-03 5:38 a.m., John Paul Adrian Glaubitz wrote:
> I can confirm that adding "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS
> in bootstrap/Makefile.am fixes the problem for me on 32-bit PowerPC on Debian.
It also fixes the build on Debian hppa.

Dave

-- 
John David Anglin  dave.anglin@bell.net






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#45214: guile segfaults on 32-bit big-endian targets
  2021-10-04 16:08           ` John David Anglin
@ 2021-10-04 16:11             ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 20+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-10-04 16:11 UTC (permalink / raw)
  To: dave.anglin, efraim, 45214, deller, schwab, debian

On 10/4/21 18:08, John David Anglin wrote:
> On 2021-10-03 5:38 a.m., John Paul Adrian Glaubitz wrote:
>> I can confirm that adding "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS
>> in bootstrap/Makefile.am fixes the problem for me on 32-bit PowerPC on Debian.
>
> It also fixes the build on Debian hppa.

And m68k as I verified today.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913






^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-10-04 16:11 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-12 21:26 bug#45214: guile segfaults on 32-bit big-endian targets John Paul Adrian Glaubitz
2020-12-12 22:00 ` John David Anglin
2020-12-12 22:02   ` John Paul Adrian Glaubitz
2021-02-25 15:24     ` Efraim Flashner
2021-04-14 14:18       ` Efraim Flashner
2021-04-14 19:19         ` John Paul Adrian Glaubitz
2021-04-15 11:50           ` Efraim Flashner
2021-04-15 13:23             ` John Paul Adrian Glaubitz
2021-10-03  9:38         ` John Paul Adrian Glaubitz
2021-10-04 16:08           ` John David Anglin
2021-10-04 16:11             ` John Paul Adrian Glaubitz
2020-12-12 22:21 ` John David Anglin
2020-12-12 22:30   ` John David Anglin
2020-12-12 22:44     ` John David Anglin
2020-12-12 22:47       ` John Paul Adrian Glaubitz
2020-12-12 23:22         ` John David Anglin
2020-12-13 18:06         ` John David Anglin
2020-12-13 18:08           ` John Paul Adrian Glaubitz
2021-02-08 23:24   ` John David Anglin
2021-02-09 13:03     ` John David Anglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).