All of lore.kernel.org
 help / color / mirror / Atom feed
* Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
@ 2011-08-25 10:37 Rolf Eike Beer
  2011-08-25 14:06 ` Carlos O'Donell
  0 siblings, 1 reply; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-25 10:37 UTC (permalink / raw)
  To: linux-parisc

First something to the machine: C3600 running Gentoo.

Kernel: 2.6.38.4
Glibc: 2.12.2
Binutils: 2.21.1
Gcc: 4.5.3

I tried to compile CMake, branch next, revision
60b6b190cb569a18b6cf415d85ff59fa120a1035. The exact version isn't really
important as I remember that problem for quite a while, it's just for
reference.

I have a working version of CMake 2.8.4 installed, no idea with which
compiler that was built (I updated gcc every now and then as they became
stable on Gentoo). Binutils used to build that CMake was very likely
2.20.1.

If I just use "cmake /path/to/cmake/source/ && make" I get this result:

Linking CXX executable ../bin/ccmake
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String,
std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_M_insert_unique(std::pair<cmsys::String const, int>
const&)]+0xbc): cannot reach
00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
recompile with -ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String,
std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_M_insert_unique(std::pair<cmsys::String const, int>
const&)]+0xbc): cannot handle R_PARISC_PCREL17F for
std::_Rb_tree<cmsys::String, std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_S_right(std::_Rb_tree_node_base*)
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

If I hack the master CMakeLists.txt to contain
"ADD_DEFINITIONS(-march=2.0)" at the very beginning everything compiles
fine. But if I run the compiled cmake it will hang in an endless loop
somewhere. It does not do any system calls then, but it eats up 100% CPU.

I very much doubt that this is a CMake breakage as CMake has many nightly
builds and tests on different platforms that work and I see this bug since
a while (likely months).

Can someone have a look or give some hints?

Eike

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-25 10:37 Link error in CMake for HPPA1.1, wrong result for HPPA 2.0 Rolf Eike Beer
@ 2011-08-25 14:06 ` Carlos O'Donell
  2011-08-25 15:21   ` Rolf Eike Beer
                     ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Carlos O'Donell @ 2011-08-25 14:06 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc

On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
> const&)]+0xbc): cannot reach
> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
> recompile with -ffunction-sections

So did you recompile with -ffunction-sections?

The basic problem is that the linker was unable to insert a jump
to the requested function because it was too far away. Some targets
like hppa have short branch distances and we use intermediate stub
tables to get around that. However, we can't insert stub tables just
anywhere, they need to go between sections. Therefore you need to
break up this object file.

Cheers,
Carlos.

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-25 14:06 ` Carlos O'Donell
@ 2011-08-25 15:21   ` Rolf Eike Beer
  2011-08-25 15:46   ` John David Anglin
  2011-08-26  8:00   ` Rolf Eike Beer
  2 siblings, 0 replies; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-25 15:21 UTC (permalink / raw)
  To: linux-parisc

> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>> const&)]+0xbc): cannot reach
>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>> recompile with -ffunction-sections
>
> So did you recompile with -ffunction-sections?
>
> The basic problem is that the linker was unable to insert a jump
> to the requested function because it was too far away. Some targets
> like hppa have short branch distances and we use intermediate stub
> tables to get around that. However, we can't insert stub tables just
> anywhere, they need to go between sections. Therefore you need to
> break up this object file.

So this is just that the object file sometime grew too big to fit into the
small jump stuff?

I'll try tomorrow and see if it works.

Eike

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-25 14:06 ` Carlos O'Donell
  2011-08-25 15:21   ` Rolf Eike Beer
@ 2011-08-25 15:46   ` John David Anglin
  2011-08-29  8:12     ` Rolf Eike Beer
  2011-08-26  8:00   ` Rolf Eike Beer
  2 siblings, 1 reply; 11+ messages in thread
From: John David Anglin @ 2011-08-25 15:46 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Rolf Eike Beer, linux-parisc

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

On 8/25/2011 10:06 AM, Carlos O'Donell wrote:
> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>> const&)]+0xbc): cannot reach
>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>> recompile with -ffunction-sections
> So did you recompile with -ffunction-sections?
>
> The basic problem is that the linker was unable to insert a jump
> to the requested function because it was too far away. Some targets
> like hppa have short branch distances and we use intermediate stub
> tables to get around that. However, we can't insert stub tables just
> anywhere, they need to go between sections. Therefore you need to
> break up this object file.
I think there is a real bug here but nobody has provided a test case.  
-ffunction-sections
probably won't help.

Stub sizes vary depending on whether PIC code or non PIC code is being 
generated.
We need a bigger stub table for PIC C++ code as C++ tends to generate a 
lot of small
routines.

I've attached the GCC part of the change.  There's also a binutils patch 
which I can't
access at the moment.

Dave

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


[-- Attachment #2: pcrel.d --]
[-- Type: text/plain, Size: 1689 bytes --]

Index: config/pa/pa.c
===================================================================
--- config/pa/pa.c	(revision 178012)
+++ config/pa/pa.c	(working copy)
@@ -7385,7 +7385,7 @@
     return 24;
   else
     {
-      if (!TARGET_LONG_CALLS && distance < 240000)
+      if (!TARGET_LONG_CALLS && distance < MAX_PCREL17F_OFFSET)
 	return 8;
 
       if (TARGET_LONG_ABS_CALL && !flag_pic)
@@ -7598,7 +7598,7 @@
   /* pc-relative branch.  */
   if (!TARGET_LONG_CALLS
       && ((TARGET_PA_20 && !sibcall && distance < 7600000)
-	  || distance < 240000))
+	  || distance < MAX_PCREL17F_OFFSET))
     length += 8;
 
   /* 64-bit plabel sequence.  */
@@ -7957,7 +7957,7 @@
   if (TARGET_FAST_INDIRECT_CALLS
       || (!TARGET_PORTABLE_RUNTIME
 	  && ((TARGET_PA_20 && !TARGET_SOM && distance < 7600000)
-	      || distance < 240000)))
+	      || distance < MAX_PCREL17F_OFFSET)))
     return 8;
 
   if (flag_pic)
Index: config/pa/pa.h
===================================================================
--- config/pa/pa.h	(revision 178012)
+++ config/pa/pa.h	(working copy)
@@ -1512,3 +1512,12 @@
 #undef TARGET_HAVE_TLS
 #define TARGET_HAVE_TLS true
 #endif
+
+/* The maximum offset in bytes for a PA 1.X pc-relative call to the
+   tail of the preceding stub table.  The selected offsets have been
+   chosen to allow approximately one call stub for every 86 instructions.
+   A long branch stub is two instructions when not generating PIC code.
+   More space is allowed for stubs when generating PIC code since HP-UX
+   and Linux import stubs are seven and four instructions, respectively.  */  
+#define MAX_PCREL17F_OFFSET \
+  (flag_pic ? (TARGET_HPUX ? 198164 : 221312) : 240000)

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-25 14:06 ` Carlos O'Donell
  2011-08-25 15:21   ` Rolf Eike Beer
  2011-08-25 15:46   ` John David Anglin
@ 2011-08-26  8:00   ` Rolf Eike Beer
  2 siblings, 0 replies; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-26  8:00 UTC (permalink / raw)
  To: linux-parisc

> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>> const&)]+0xbc): cannot reach
>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>> recompile with -ffunction-sections
>
> So did you recompile with -ffunction-sections?
>
> The basic problem is that the linker was unable to insert a jump
> to the requested function because it was too far away. Some targets
> like hppa have short branch distances and we use intermediate stub
> tables to get around that. However, we can't insert stub tables just
> anywhere, they need to go between sections. Therefore you need to
> break up this object file.

If I add -ffunction-section then ccmake (and cmake and cpack) build fine,
but ctest fails:

Linking CXX executable ../bin/ctest
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40):
cannot reach 00008647__ZNSaIcEC1Ev@@GLIBCXX_3.4+0, recompile with
-ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40):
cannot handle R_PARISC_PCREL17F for
std::allocator<char>::allocator()@@GLIBCXX_3.4
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

This is the same static library that causes problems, but this time on a
different executable. So I think John is right and there is really a bug
somewhere.

Just for reference, this are the sizes of the binaries that I currently
have on my system:

-rwxr-xr-x 1 root root 3080228 Apr 26 12:51 /usr/bin/ccmake
-rwxr-xr-x 1 root root 3050408 Apr 26 12:51 /usr/bin/cmake
-rwxr-xr-x 1 root root 4092940 Apr 26 12:51 /usr/bin/ctest

And this is what happens with -ffunction-sections for those that compile:

-rwxr-xr-x 1 buildbot buildbot  9738726 Aug 26 09:15 ccmake
-rwxr-xr-x 1 buildbot buildbot  9608066 Aug 26 09:16 cmake
-rwxr-xr-x 1 buildbot buildbot 10302152 Aug 26 09:16 cpack

I have no idea how big the current results would get as every of the 4
possible candidates fails to link. libCMakeLib.a is 21149998 bytes.

Eike

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-25 15:46   ` John David Anglin
@ 2011-08-29  8:12     ` Rolf Eike Beer
  2011-08-29  9:47       ` Rolf Eike Beer
  2011-08-29 14:38       ` John David Anglin
  0 siblings, 2 replies; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-29  8:12 UTC (permalink / raw)
  To: linux-parisc

> On 8/25/2011 10:06 AM, Carlos O'Donell wrote:
>> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>>> const&)]+0xbc): cannot reach
>>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>>> recompile with -ffunction-sections
>> So did you recompile with -ffunction-sections?
>>
>> The basic problem is that the linker was unable to insert a jump
>> to the requested function because it was too far away. Some targets
>> like hppa have short branch distances and we use intermediate stub
>> tables to get around that. However, we can't insert stub tables just
>> anywhere, they need to go between sections. Therefore you need to
>> break up this object file.
> I think there is a real bug here but nobody has provided a test case.
> -ffunction-sections
> probably won't help.

Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
everything works fine. I'll file a bug report tonight.

Eike

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-29  8:12     ` Rolf Eike Beer
@ 2011-08-29  9:47       ` Rolf Eike Beer
  2011-08-29 14:38       ` John David Anglin
  1 sibling, 0 replies; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-29  9:47 UTC (permalink / raw)
  To: linux-parisc

>> On 8/25/2011 10:06 AM, Carlos O'Donell wrote:
>>> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>>>> const&)]+0xbc): cannot reach
>>>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>>>> recompile with -ffunction-sections
>>> So did you recompile with -ffunction-sections?
>>>
>>> The basic problem is that the linker was unable to insert a jump
>>> to the requested function because it was too far away. Some targets
>>> like hppa have short branch distances and we use intermediate stub
>>> tables to get around that. However, we can't insert stub tables just
>>> anywhere, they need to go between sections. Therefore you need to
>>> break up this object file.
>> I think there is a real bug here but nobody has provided a test case.
>> -ffunction-sections
>> probably won't help.
>
> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
> everything works fine. I'll file a bug report tonight.

Everything _compiles_ fine. The process later goes into an endless loop
again if I call the compiled binary with a source directory. This does not
happen with arguments like "--help" or "--version", so I overlooked that
at first.

So:
-compiling/linking with g++ 4.5 fails
-compiling/linking with g++ 4.4 works, but the result is unusable

John, do you need anything more from me? Things I can test? Which version
is your patch against?

Eike


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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-29  8:12     ` Rolf Eike Beer
  2011-08-29  9:47       ` Rolf Eike Beer
@ 2011-08-29 14:38       ` John David Anglin
  2011-08-29 18:31         ` Rolf Eike Beer
  1 sibling, 1 reply; 11+ messages in thread
From: John David Anglin @ 2011-08-29 14:38 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc

On 8/29/2011 4:12 AM, Rolf Eike Beer wrote:
>> On 8/25/2011 10:06 AM, Carlos O'Donell wrote:
>>> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote:
>>>> const&)]+0xbc): cannot reach
>>>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
>>>> recompile with -ffunction-sections
>>> So did you recompile with -ffunction-sections?
>>>
>>> The basic problem is that the linker was unable to insert a jump
>>> to the requested function because it was too far away. Some targets
>>> like hppa have short branch distances and we use intermediate stub
>>> tables to get around that. However, we can't insert stub tables just
>>> anywhere, they need to go between sections. Therefore you need to
>>> break up this object file.
>> I think there is a real bug here but nobody has provided a test case.
>> -ffunction-sections
>> probably won't help.
> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
> everything works fine. I'll file a bug report tonight.
>
Interesting, there's not much difference in the PA backend for these two 
versions.

Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and 
I'll try to
duplicate the problem.

Thanks,
Dave

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


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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-29 14:38       ` John David Anglin
@ 2011-08-29 18:31         ` Rolf Eike Beer
  2011-09-07 23:35           ` John David Anglin
  0 siblings, 1 reply; 11+ messages in thread
From: Rolf Eike Beer @ 2011-08-29 18:31 UTC (permalink / raw)
  To: linux-parisc

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

You wrote:
> On 8/29/2011 4:12 AM, Rolf Eike Beer wrote:

> > Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
> > everything works fine. I'll file a bug report tonight.
> 
> Interesting, there's not much difference in the PA backend for these two
> versions.
> 
> Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and
> I'll try to
> duplicate the problem.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-08-29 18:31         ` Rolf Eike Beer
@ 2011-09-07 23:35           ` John David Anglin
  2011-09-08 15:22             ` Carlos O'Donell
  0 siblings, 1 reply; 11+ messages in thread
From: John David Anglin @ 2011-09-07 23:35 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: linux-parisc


On 29-Aug-11, at 2:31 PM, Rolf Eike Beer wrote:

> You wrote:
>> On 8/29/2011 4:12 AM, Rolf Eike Beer wrote:
>
>>> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
>>> everything works fine. I'll file a bug report tonight.
>>
>> Interesting, there's not much difference in the PA backend for  
>> these two
>> versions.
>>
>> Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug  
>> report and
>> I'll try to
>> duplicate the problem.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230
>
> Eike


The problem appears to be that comdat groups and stubs don't get along
with each other.  Comdat groups seem to get merged and this can result
in out of range branches.

Linking with the --unique='.text.*' option avoids the error, but this  
probably
breaks comdat and discard support.

For now, I think the best solution (untested) is to configure GCC with  
the
--disable-comdat option.

I'm going to file a binutils PR.

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




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

* Re: Link error in CMake for HPPA1.1, wrong result for HPPA 2.0
  2011-09-07 23:35           ` John David Anglin
@ 2011-09-08 15:22             ` Carlos O'Donell
  0 siblings, 0 replies; 11+ messages in thread
From: Carlos O'Donell @ 2011-09-08 15:22 UTC (permalink / raw)
  To: John David Anglin; +Cc: Rolf Eike Beer, linux-parisc

On 9/7/2011 7:35 PM, John David Anglin wrote:
> 
> On 29-Aug-11, at 2:31 PM, Rolf Eike Beer wrote:
> 
>> You wrote:
>>> On 8/29/2011 4:12 AM, Rolf Eike Beer wrote:
>>
>>>> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6
>>>> everything works fine. I'll file a bug report tonight.
>>>
>>> Interesting, there's not much difference in the PA backend for these two
>>> versions.
>>>
>>> Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and
>>> I'll try to
>>> duplicate the problem.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230
>>
>> Eike
> 
> 
> The problem appears to be that comdat groups and stubs don't get along
> with each other.  Comdat groups seem to get merged and this can result
> in out of range branches.
> 
> Linking with the --unique='.text.*' option avoids the error, but this probably
> breaks comdat and discard support.
> 
> For now, I think the best solution (untested) is to configure GCC with the
> --disable-comdat option.
> 
> I'm going to file a binutils PR.

Interesting analysis.

I don't see how you can fix this though.

Support multiple comdat groups and arrange for the merging to
happen correctly?

Cheers,
Carlos.


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

end of thread, other threads:[~2011-09-08 15:22 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-25 10:37 Link error in CMake for HPPA1.1, wrong result for HPPA 2.0 Rolf Eike Beer
2011-08-25 14:06 ` Carlos O'Donell
2011-08-25 15:21   ` Rolf Eike Beer
2011-08-25 15:46   ` John David Anglin
2011-08-29  8:12     ` Rolf Eike Beer
2011-08-29  9:47       ` Rolf Eike Beer
2011-08-29 14:38       ` John David Anglin
2011-08-29 18:31         ` Rolf Eike Beer
2011-09-07 23:35           ` John David Anglin
2011-09-08 15:22             ` Carlos O'Donell
2011-08-26  8:00   ` Rolf Eike Beer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.