public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc-3.1 2002-04-03 libjava failures on sparc-linux?
@ 2002-04-05  9:29 Christian Jönsson
  2002-04-05  9:50 ` Christian Jönsson
  0 siblings, 1 reply; 19+ messages in thread
From: Christian Jönsson @ 2002-04-05  9:29 UTC (permalink / raw)
  To: Tom Tromey; +Cc: java

Hej Tom.

I am test building the gcc-3.1 prereleases on sparc-linux, n.b.,
debian, no more sparc support from redhat...

The results of the testsuite is getting better and better, but libjava
still has a lot of failures.

Could you perhaps elaborate a little on what you think might be the
causes behind these failures?

I know that the support for sparc32 in the linux kernel is lagging,
there might be such problems. And, it's a 2.2.x kernel I'm running,
2.4.x is not stable enough yet (ever?) on smp sun4m.

Cheers,

/ChJ



This was on a Debian Woody (test release) sun4m system using

binutils                           2.12.90.0.1-1
dejagnu                            1.4.2-1.1
gcc                                2:2.95.4-14 (Debian prerelease)
gcc-2.95			   1:2.95.4-5 (Debian prerelease)
kernel-image-2.2.20-sun4dm-smp     9
libc6                              2.2.5-3 (now libc6-2.2.5-4)






^ permalink raw reply	[flat|nested] 19+ messages in thread
* RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
@ 2002-04-09 23:39 Boehm, Hans
  2002-04-10  5:17 ` Christian Jönsson
  0 siblings, 1 reply; 19+ messages in thread
From: Boehm, Hans @ 2002-04-09 23:39 UTC (permalink / raw)
  To: 'Christian Jönsson', Tom Tromey; +Cc: Boehm, Hans, java

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> ibjava/testsuite/cxxtest 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> 1349		q = *p;
> (gdb) bt
> #0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x506d7058 in GC_push_all_stack_partially_eager (
>     bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xeaffe5bc "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386

This is actually rather suggestive.  It was trying to mark a stack between
0xeaffe3d4 and 0xf0000000.  That's a big stack.  I suspect one of the
following:

1) Java is compiled with thread support, but the collector gets configures
without GC_LINUX_THREADS defined.  Thus it's trying to mark between a thread
stack pointer and the base of the main stack.

2) The default stack base of (specified in gcconfig.h) of 0xf0000000 is
wrong on your machine.  Try stopping a toy program in main and print $sp
from gdb to see whether the stack base looks plausible.

Hans

^ permalink raw reply	[flat|nested] 19+ messages in thread
* RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
@ 2002-04-10 12:21 Boehm, Hans
  2002-04-15  0:13 ` Christian Jönsson
  0 siblings, 1 reply; 19+ messages in thread
From: Boehm, Hans @ 2002-04-10 12:21 UTC (permalink / raw)
  To: 'Christian Jönsson', Boehm, Hans; +Cc: Tom Tromey, java

The new trace looks very similar to the old one to me.  There's still a lot
of space between "bottom" and "top" in GC_push_all_eager.  Does the stack
base look plausible?  If you stop the program in main(), what's $sp?

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> Sent: Wednesday, April 10, 2002 1:20 AM
> To: Boehm, Hans
> Cc: Tom Tromey; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Tue, Apr 09, 2002 at 06:19:01PM -0700, Boehm, Hans wrote:
> > > -----Original Message-----
> > > From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> > > (gdb) r
> > > Starting program: 
> > > /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> > > ibjava/testsuite/cxxtest 
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> > >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > > 1349		q = *p;
> > > (gdb) bt
> > > #0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 
> "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> > >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > > #1  0x506d7058 in GC_push_all_stack_partially_eager (
> > >     bottom=0xeaffe3d4 "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
> > >     cold_gc_frame=0xeaffe5bc "") at 
> > > /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> > 
> > This is actually rather suggestive.  It was trying to mark 
> a stack between
> > 0xeaffe3d4 and 0xf0000000.  That's a big stack.  I suspect 
> one of the
> > following:
> > 
> > 1) Java is compiled with thread support, but the collector 
> gets configures
> > without GC_LINUX_THREADS defined.  Thus it's trying to mark 
> between a thread
> > stack pointer and the base of the main stack.
> > 
> > 2) The default stack base of (specified in gcconfig.h) of 
> 0xf0000000 is
> > wrong on your machine.  Try stopping a toy program in main 
> and print $sp
> > from gdb to see whether the stack base looks plausible.
> 
> I'm afraid I ran this test on a ss20 UP machine, and not the ss20 SMP
> machine I built on... Here's a new run for gcc-3.1 2002-04-08.
> 
> This was on a Debian Woody (test release) sun4m system with these
> packages:
> 
> binutils                           2.12.90.0.1-1
> dejagnu                            1.4.2-1.1
> gcc                                2:2.95.4-14 (Debian prerelease)
> gcc-2.95			   1:2.95.4-5 (Debian prerelease)
> kernel-image-2.2.20-sun4dm-smp     9
> libc6                              2.2.5-4
> 
> LAST_UPDATED: Tue Apr  9 06:34:44 UTC 2002
> 
> 
> # This directory was configured as follows:
> /share2/gcc-rel/gcc/configure --host=sparc-linux 
> --prefix=/usr --enable-shared --with-gnu-as --with-gnu-ld 
> --with-system-zlib --enable-long-long --enable-nlls 
> --enable-symvers --without-x --without-included-gettext 
> --disable-checking
> 
> 
> i.e., no threads as some suspect threads problems.
> 
> 
> chj@fw:/share2/gcc-rel/objdir/sparc-linux/libjava/testsuite$ 
> env 
> LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:.:/usr/lib/d
> ebug ~/gdb cxxtest
> GNU gdb 5.1.90_20020403
> Copyright 2002 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 "sparc-linux"...
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> 1349		q = *p;
> (gdb) bt
> #0  0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x506d9cc0 in GC_push_all_stack_partially_eager (
>     bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xeaffe62c "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> #2  0x506dbaf0 in GC_push_current_stack (cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
> #3  0x506dbc58 in GC_push_roots (all=1, cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
> #4  0x506d7958 in GC_mark_some (cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
> #5  0x506cdb20 in GC_stopped_mark (stop_func=0x506ccca0 
> <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
> #6  0x506cd6a8 in GC_try_to_collect_inner (
>     stop_func=0x506ccca0 <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
> #7  0x506dce14 in GC_init_inner () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:673
> #8  0x506dc880 in GC_init () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:455
> #9  0x506d3ac8 in GC_init_gcj_malloc (mp_index=0, mp=0x506c9c14)
>     at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
> #10 0x506ca870 in _Jv_InitGC() () at 
> /share2/gcc-rel/gcc/libjava/boehm.cc:465
> #11 0x5053f8fc in _Jv_CreateJavaVM(void*) ()
>     at /share2/gcc-rel/gcc/libjava/prims.cc:892
> #12 0x5053fd20 in _Jv_RunMain(java::lang::Class*, char 
> const*, int, char const**, bool) (klass=0x20f74, name=0x0, 
> argc=1, argv=0xeaffea84, is_jar=false)
>     at /share2/gcc-rel/gcc/libjava/prims.cc:982
> #13 0x00010aac in main (argc=1, argv=0xeaffea84) at /tmp/cclCWPMk.i:11
> (gdb) c
> Continuing.
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) 
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread
* RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
@ 2002-04-15 20:03 Boehm, Hans
  2002-04-15 23:08 ` Christian Jönsson
  2002-04-16  3:31 ` Christian Jönsson
  0 siblings, 2 replies; 19+ messages in thread
From: Boehm, Hans @ 2002-04-15 20:03 UTC (permalink / raw)
  To: 'Christian Jönsson', Boehm, Hans; +Cc: Tom Tromey, java

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

That stack pointer value doesn't look a lot like GC_stackbottom.  Just for
grins, could you try the attached (completely untested) patch?  This makes
linux/SPARC determine GC_stackbottom in the same way as on other Linux
platforms, i.e. it first cheats and looks for a private glibc symbol, and
reads the stack base from /proc if that fails.

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> Sent: Sunday, April 14, 2002 1:16 PM
> To: Boehm, Hans
> Cc: Tom Tromey; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Wed, Apr 10, 2002 at 11:11:19AM -0700, Boehm, Hans wrote:
> > The new trace looks very similar to the old one to me.  
> There's still a lot
> > of space between "bottom" and "top" in GC_push_all_eager.  
> Does the stack
> > base look plausible?  If you stop the program in main(), what's $sp?
> > 
> > Hans
> 
> Well, here's what's in there for today's (Sun Apr 14 07:33:16 
> UTC 2002):
> 
> Current directory is 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/
> GNU gdb 5.1.90_20020403
> Copyright 2002 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 "sparc-linux"...
> (gdb) break main
> Breakpoint 1 at 0x10ac0: file /tmp/cctyn6m2.i, line 10.
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 
> 
> Breakpoint 1, main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:10
> 10	/tmp/cctyn6m2.i: No such file or directory.
> 	in /tmp/cctyn6m2.i
> (gdb) print $sp
> $1 = -385881272
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> (gdb) bt
> #0  0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x507006e8 in GC_push_all_stack_partially_eager (
>     bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xe8ffe81c "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> #2  0x5070251c in GC_push_current_stack (cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
> #3  0x50702684 in GC_push_roots (all=1, cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
> #4  0x506fe380 in GC_mark_some (cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
> #5  0x506f4548 in GC_stopped_mark (stop_func=0x506f36c8 
> <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
> #6  0x506f40d0 in GC_try_to_collect_inner (
>     stop_func=0x506f36c8 <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
> #7  0x50703840 in GC_init_inner () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:673
> #8  0x507032ac in GC_init () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:455
> #9  0x506fa4f0 in GC_init_gcj_malloc (mp_index=0, mp=0x506f063c)
>     at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
> #10 0x506f1298 in _Jv_InitGC() () at 
> /share2/gcc-rel/gcc/libjava/boehm.cc:465
> #11 0x5053e914 in _Jv_CreateJavaVM(void*) ()
>     at /share2/gcc-rel/gcc/libjava/prims.cc:892
> #12 0x5053ed38 in _Jv_RunMain(java::lang::Class*, char 
> const*, int, char const**, bool) (klass=0x2101c, name=0x0, 
> argc=1, argv=0xe8ffec74, is_jar=false)
>     at /share2/gcc-rel/gcc/libjava/prims.cc:982
> #13 0x00010aec in main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:11
> (gdb) print $sp
> $2 = -385882800
> (gdb) call GC_dump()
> ***Static roots:
> From 0x20e58 to 0x21498 
> From 0x50039b38 to 0x50039d58  (temporary)
> From 0x500df7c8 to 0x500f3ff8  (temporary)
> From 0x50186118 to 0x50188470  (temporary)
> From 0x5019fed0 to 0x501a07b8  (temporary)
> From 0x502d7000 to 0x502e21a8  (temporary)
> From 0x50796970 to 0x508ae1b0  (temporary)
> From 0x508cbc68 to 0x508cd3e8  (temporary)
> From 0x508de000 to 0x508de370  (temporary)
> Total size: 1294760
> 
> ***Heap sections:
> Total heap size: 65536
> Section 0 from 0x44000 to 0x54000 0/16 blacklisted
> 
> ***Free blocks:
> Free list 16 (Total size 65536):
> 	0x44000 size 65536 not black listed
> Total of 65536 bytes on free list
> 
> ***Blocks in use:
> (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
> #_marks_set)
> 
> blocks = 0, bytes = 0
> (gdb) c
> Continuing.
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) quit
> 
> Debugger finished
> 
> Cheers,
> 
> /ChJ
> 


[-- Attachment #2: sparc.diff --]
[-- Type: application/octet-stream, Size: 525 bytes --]

--- gcconfig.h	Mon Apr  8 16:37:20 2002
+++ gcconfig.h.sparc	Mon Apr 15 19:53:46 2002
@@ -815,11 +815,10 @@
       extern int _etext;
 #     define DATAEND (&_end)
 #     define SVR4
+#     define LINUX_STACKBOTTOM
 #     ifdef __arch64__
-#       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
 #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, &_etext)
 #     else
-#       define STACKBOTTOM ((ptr_t) 0xf0000000)
 #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, &_etext)
 #     endif
 #   endif

^ permalink raw reply	[flat|nested] 19+ messages in thread
* RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
@ 2002-04-17 10:19 Boehm, Hans
  2002-04-17 10:54 ` Christian Jönsson
  2002-04-17 13:00 ` Christian Jönsson
  0 siblings, 2 replies; 19+ messages in thread
From: Boehm, Hans @ 2002-04-17 10:19 UTC (permalink / raw)
  To: 'Christian Jönsson', Tom Tromey; +Cc: Boehm, Hans, java

I think this part of the patch should be checked into both the branch and
trunk.  If in parallel someone else could try this on other Linux/SPARC
machines, that would help to verify that the main stack base is always
correctly reported in /proc.  But the current code is very hard to defend,
at least given the fact that it isn't always correct.

If you would like me to check it in, please let me know.

I will hold off on the proposed/conjectured Solaris/64 patch since nobody
has been able to test that.

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:christian@j-son.org]
> Sent: Wednesday, April 17, 2002 12:28 AM
> To: Tom Tromey
> Cc: Boehm, Hans; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Wed, Apr 17, 2002 at 09:22:36AM +0200, chj wrote:
> > On Tue, Apr 16, 2002 at 10:08:45AM -0600, Tom Tromey wrote:
> > > >>>>> "ChJ" == Christian Jönsson 
> <c.christian.joensson@telia.com> writes:
> > > 
> > > ChJ> I applied it to Hans et als. gc6.1alpha4 sources, it seems to
> > > ChJ> work there.
> > > 
> > > Great.
> > > 
> > > ChJ> So Hans, what do we do now? Incorporate your patch 
> into the gcc
> > > ChJ> 3.1 branch and trunk? Test it first in gc6.1alpha5?
> > > 
> > > As I understand it, you couldn't apply this patch to the 
> GC currently
> > > in the gcc tree, right?  Could you modify the patch so it applies
> > > (apply it by hand somehow) and then test that version of the GC?
> > > 
> > > If that works, we will definitely check it in.
> > 
> > I have used the attached patch (based on Hans' first 
> suggested patch).
> 
> ehrm, here it is:
> 
> *** include/private/gcconfig.h.orig	Tue Apr 16 19:08:52 2002
> --- include/private/gcconfig.h	Tue Apr 16 19:14:08 2002
> ***************
> *** 820,830 ****
>         extern int _etext[];
>   #     define DATAEND (_end)
>   #     define SVR4
>   #     ifdef __arch64__
> - #       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
>   #     else
> - #       define STACKBOTTOM ((ptr_t) 0xf0000000)
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
>   #     endif
>   #   endif
> --- 820,829 ----
>         extern int _etext[];
>   #     define DATAEND (_end)
>   #     define SVR4
> + #     define LINUX_STACKBOTTOM
>   #     ifdef __arch64__
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
>   #     else
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
>   #     endif
>   #   endif
> 
> 
> > The results are good (however, I happened to throw an an additional
> > --enable-threads that I know cause troubles on sparc32/linux). 
> > 
> > I'd say the proposed patch works for sparc32, and I know Hans has
> > a proposed patch for "all" sparc targets that I hope is in 
> the process
> > of being tested by folks having those arch available.
> 
> <snip>
> 
> Cheers,
> 
> /ChJ
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread
end of thread, other threads:[~2002-04-17 17:54 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-05  9:29 gcc-3.1 2002-04-03 libjava failures on sparc-linux? Christian Jönsson
2002-04-05  9:50 ` Christian Jönsson
2002-04-08 13:15   ` Tom Tromey
2002-04-08 14:27     ` Christian Jönsson
2002-04-09  9:48       ` Christian Jönsson
2002-04-09 15:02         ` Tom Tromey
2002-04-09 23:39 Boehm, Hans
2002-04-10  5:17 ` Christian Jönsson
2002-04-10 12:21 Boehm, Hans
2002-04-15  0:13 ` Christian Jönsson
2002-04-15 20:03 Boehm, Hans
2002-04-15 23:08 ` Christian Jönsson
2002-04-16  3:31 ` Christian Jönsson
2002-04-16 16:33   ` Tom Tromey
2002-04-17  0:28     ` Christian Jönsson
2002-04-17  1:05       ` Christian Jönsson
2002-04-17 10:19 Boehm, Hans
2002-04-17 10:54 ` Christian Jönsson
2002-04-17 13:00 ` Christian Jönsson

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).