* Re: Problems building GNAT on OS X with top-of-tree [not found] <E5B21272-E13A-11D6-B07C-000393D76DAA@apple.com> @ 2002-10-16 13:28 ` Geert Bosch 2002-10-16 15:00 ` Dale Johannesen 0 siblings, 1 reply; 14+ messages in thread From: Geert Bosch @ 2002-10-16 13:28 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc On Wednesday, Oct 16, 2002, at 15:10 America/New_York, Dale Johannesen wrote: > OK, the problem is code that looks like this: > > .comm _ada__exceptions__subprogram_descriptors,8 > .... > addis > r9,r31,ha16(_ada__exceptions__subprogram_descriptors-L42$pb) > lwz > r9,lo16(_ada__exceptions__subprogram_descriptors-L42$pb)(r9) > > This object looks like something the Ada FE created. > .comm data must be addressed by the non_lazy_ptr mechanism: > > int x[20]; > main() { foo(x); } > > addis r9,r31,ha16(L_x$non_lazy_ptr-L1$pb) > lwz r3,lo16(L_x$non_lazy_ptr-L1$pb)(r9) > .comm _x,80 > .data > .non_lazy_symbol_pointer > L_x$non_lazy_ptr: > .indirect_symbol _x > .long 0 > > The mechanism is in config/darwin.c and config/rs6000/rs6000.c. > machopic_legitimize_pic_address is probably a good place to start. > OK, I see. Indeed, using -fno-common eliminates/suppresses the problem. However, I don't see how the front end should have to know about these details. I looked at darwin.c, and I see the implementation of the scheme using lazy and non-lazy pointers, but there does not seem to be any documentation at a sufficiently high level to be able to understand what is going on there. I'm focussing now on finding out why this problems does not occur with the C front end, which seems to use the same method for outputting variables in the common section. -Geert ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-16 13:28 ` Problems building GNAT on OS X with top-of-tree Geert Bosch @ 2002-10-16 15:00 ` Dale Johannesen 2002-10-17 14:52 ` Geert Bosch 0 siblings, 1 reply; 14+ messages in thread From: Dale Johannesen @ 2002-10-16 15:00 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc On Wednesday, October 16, 2002, at 12:52 PM, Geert Bosch wrote: > OK, I see. Indeed, using -fno-common eliminates/suppresses the problem. > However, I don't see how the front end should have to know > about these details. I looked at darwin.c, and I see the implementation > of the scheme using lazy and non-lazy pointers, but there does not > seem to be any documentation at a sufficiently high level to be able > to understand what is going on there. Right. I didn't write it, and I still find it confusing. > I'm focussing now on finding out why this problems does not occur with > the C front end, which seems to use the same method for outputting > variables in the common section. You could do that. Alternatively, I see that the correct sequence is generated for ada__exceptions__null_occurrence, which is also a .comm symbol. You might look and see what's different about the symbols. This is probably just a matter of getting some field set correctly. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-16 15:00 ` Dale Johannesen @ 2002-10-17 14:52 ` Geert Bosch 2002-10-17 15:00 ` Dale Johannesen 2002-10-17 15:02 ` Dale Johannesen 0 siblings, 2 replies; 14+ messages in thread From: Geert Bosch @ 2002-10-17 14:52 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc Dale wrote: >> I'm focussing now on finding out why this problems does not occur with >> the C front end, which seems to use the same method for outputting >> variables in the common section. > > You could do that. Alternatively, I see that the correct sequence is > generated for ada__exceptions__null_occurrence, which is also a .comm > symbol. You might look and see what's different about the symbols. > This is probably just a matter of getting some field set correctly. Actually, I tried to build with -fno-common and a few files later, while compiling ali.adb with stage1/gnat, we fail in a clearer way: ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 30708. ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 30704. ali.s:unknown:Undefined local symbol L149$pb The piece of assembly in question is: LSJR827: mflr r31 addis r31,r31,ha16(L149$pb-LSJR827) addi r31,r31,lo16(L149$pb-LSJR827) This reference is generated by machopic_function_base_name () in darwin.c, but there is no documentation as to who should generate this label... -Geert ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-17 14:52 ` Geert Bosch @ 2002-10-17 15:00 ` Dale Johannesen 2002-10-17 15:02 ` Dale Johannesen 1 sibling, 0 replies; 14+ messages in thread From: Dale Johannesen @ 2002-10-17 15:00 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc On Thursday, October 17, 2002, at 01:44 PM, Geert Bosch wrote: > ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address > 30708. > ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address > 30704. > ali.s:unknown:Undefined local symbol L149$pb > > The piece of assembly in question is: > LSJR827: > mflr r31 > addis r31,r31,ha16(L149$pb-LSJR827) > addi r31,r31,lo16(L149$pb-LSJR827) > > This reference is generated by machopic_function_base_name () in > darwin.c, > but there is no documentation as to who should generate this label... It is generated by gen_load_macho_picbase() which should be called from rs6000_emit_prologue(). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-17 14:52 ` Geert Bosch 2002-10-17 15:00 ` Dale Johannesen @ 2002-10-17 15:02 ` Dale Johannesen 2002-10-17 15:22 ` Geoffrey Keating 1 sibling, 1 reply; 14+ messages in thread From: Dale Johannesen @ 2002-10-17 15:02 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc, Geoffrey Keating On Thursday, October 17, 2002, at 01:44 PM, Geert Bosch wrote: > ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address > 30708. > ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address > 30704. > ali.s:unknown:Undefined local symbol L149$pb > > The piece of assembly in question is: > LSJR827: > mflr r31 > addis r31,r31,ha16(L149$pb-LSJR827) > addi r31,r31,lo16(L149$pb-LSJR827) Actually this looks like it is connected to Geoff's recent patch http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html which introduced the LSJR label. Geoff, is current_function_uses_pic_offset_table not getting set anywhere? That would account for his symptom. (This is probably unrelated to your earlier bug.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-17 15:02 ` Dale Johannesen @ 2002-10-17 15:22 ` Geoffrey Keating 2002-10-17 17:06 ` Dale Johannesen 0 siblings, 1 reply; 14+ messages in thread From: Geoffrey Keating @ 2002-10-17 15:22 UTC (permalink / raw) To: Dale Johannesen; +Cc: Geert Bosch, gcc On Thursday, October 17, 2002, at 02:10 PM, Dale Johannesen wrote: > > On Thursday, October 17, 2002, at 01:44 PM, Geert Bosch wrote: >> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address >> 30708. >> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address >> 30704. >> ali.s:unknown:Undefined local symbol L149$pb >> >> The piece of assembly in question is: >> LSJR827: >> mflr r31 >> addis r31,r31,ha16(L149$pb-LSJR827) >> addi r31,r31,lo16(L149$pb-LSJR827) > > Actually this looks like it is connected to Geoff's recent patch > http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html > which introduced the LSJR label. Geoff, is > current_function_uses_pic_offset_table not getting set anywhere? > That would account for his symptom. > It is supposed to be set by machopic_function_base_name, which is called to generate the label. Looking at the code, my suspicion is that the original load_macho_picbase pattern is getting deleted by flow because it appears dead, but that also deletes the label that the macho_correct_pic needs. If so, the solution is to use a real CODE_LABEL instead of having the label inside load_macho_picbase, but this will be a complex change. > (This is probably unrelated to your earlier bug.) Well, it's certainly related, in the sense that if I hadn't fixed that bug this code would now fail at runtime instead of compile-time… ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-17 15:22 ` Geoffrey Keating @ 2002-10-17 17:06 ` Dale Johannesen 2002-10-17 20:59 ` Geoffrey Keating 0 siblings, 1 reply; 14+ messages in thread From: Dale Johannesen @ 2002-10-17 17:06 UTC (permalink / raw) To: Geoffrey Keating; +Cc: Dale Johannesen, Geert Bosch, gcc On Thursday, October 17, 2002, at 02:38 PM, Geoffrey Keating wrote: > On Thursday, October 17, 2002, at 02:10 PM, Dale Johannesen wrote: >> >> Actually this looks like it is connected to Geoff's recent patch >> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html >> which introduced the LSJR label. Geoff, is >> current_function_uses_pic_offset_table not getting set anywhere? >> That would account for his symptom. >> > It is supposed to be set by machopic_function_base_name, which is > called to generate the label. Looking at the code, my suspicion is > that the original load_macho_picbase pattern is getting deleted by > flow because it appears dead, but that also deletes the label that the > macho_correct_pic needs. > > If so, the solution is to use a real CODE_LABEL instead of having the > label inside load_macho_picbase, but this will be a complex change. Hmm. How do you keep the bcl and the following label together through the scheduler? SCHED_GROUP_P used to work on labels, but it doesn't any more, and I never found another way to do it. Would a USE of the label work? >> (This is probably unrelated to your earlier bug.) > > Well, it's certainly related, in the sense that if I hadn't fixed that > bug this code would now fail at runtime instead of compile-time… (I meant Geert Bosch's earlier bug, not yours. Sorry to be unclear.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-17 17:06 ` Dale Johannesen @ 2002-10-17 20:59 ` Geoffrey Keating 0 siblings, 0 replies; 14+ messages in thread From: Geoffrey Keating @ 2002-10-17 20:59 UTC (permalink / raw) To: Dale Johannesen; +Cc: Geert Bosch, gcc On Thursday, October 17, 2002, at 02:52 PM, Dale Johannesen wrote: > > On Thursday, October 17, 2002, at 02:38 PM, Geoffrey Keating wrote: >> On Thursday, October 17, 2002, at 02:10 PM, Dale Johannesen wrote: >>> >>> Actually this looks like it is connected to Geoff's recent patch >>> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html >>> which introduced the LSJR label. Geoff, is >>> current_function_uses_pic_offset_table not getting set anywhere? >>> That would account for his symptom. >>> >> It is supposed to be set by machopic_function_base_name, which is >> called to generate the label. Looking at the code, my suspicion is >> that the original load_macho_picbase pattern is getting deleted by >> flow because it appears dead, but that also deletes the label that >> the macho_correct_pic needs. >> >> If so, the solution is to use a real CODE_LABEL instead of having the >> label inside load_macho_picbase, but this will be a complex change. > > Hmm. How do you keep the bcl and the following label together through > the scheduler? > SCHED_GROUP_P used to work on labels, but it doesn't any more, and I > never found > another way to do it. Would a USE of the label work? That's a tricky one. What you really want to do is say (parallel [(set (pc) (label_ref (code_label ...))) (set (reg:SI lr) (label_ref (code_label ...)))]) because that accurately describes what load_macho_picbase really does, but reload can't deal with that, it doesn't like jump instructions that have output reloads. Since we can't do the nice thing, probably a good second-best is, for functions that need this restore (perhaps those that have current_function_has_nonlocal_label set) to ensure that the original load_macho_picbase never gets deleted by adding a suitable USE of the PIC register. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Problems building GNAT on OS X with top-of-tree @ 2002-10-15 21:08 Geert Bosch 2002-10-16 10:43 ` Dale Johannesen 2002-10-16 10:59 ` Dale Johannesen 0 siblings, 2 replies; 14+ messages in thread From: Geert Bosch @ 2002-10-15 21:08 UTC (permalink / raw) To: gcc I am trying to get up to speed with the head of the GCC tree, but while building stage2 of the GNAT, any non-trivial file fails to compile with assembler errors as follows: stage1/xgcc -Bstage1/ -B/usr/local/powerpc-apple-darwin6.1/bin/ -c -g -O2 -gnatpg -gnata -g -O1 -fno-inline \ -I- -I. -Iada -I/Users/bosch/gcc/gcc/ada /Users/bosch/gcc/gcc/ada/a-except.adb -o ada/a-except.o a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 9408. a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 9404. a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 9296. a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 9292. a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 9216. a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 9212. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 9056. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 9052. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8868. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8864. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8680. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8676. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8572. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8568. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8532. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8528. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8452. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8448. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8360. a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 8356. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 6140. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 6136. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5980. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5976. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5952. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5948. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5824. a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 5820. a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address 5468. a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address 5464. I guess this refers to code like: addis r9,r31,ha16( L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- L42$pb) lwz r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- L42$pb)(r9) Indeed, this looks dubious and IIRC, there was a similar problem a long while ago. Do these symptoms ring a bell with anyone? If not, I'll see if I can debug this and see why this code gets generated. Thanks in advance for any help. -Geert ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-15 21:08 Geert Bosch @ 2002-10-16 10:43 ` Dale Johannesen 2002-10-16 10:59 ` Dale Johannesen 1 sibling, 0 replies; 14+ messages in thread From: Dale Johannesen @ 2002-10-16 10:43 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc On Tuesday, October 15, 2002, at 06:32 PM, Geert Bosch wrote: > a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address > 5464. > > I guess this refers to code like: > addis > r9,r31,ha16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- > L42$pb) > lwz > r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- > L42$pb)(r9) The code you quote here looks correct. Probably the definition of L42$pb is missing; it should be near the top of the function. The RTL for it should be generated by gen_load_macho_picbase() called from rs6000_emit_prologue(). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-15 21:08 Geert Bosch 2002-10-16 10:43 ` Dale Johannesen @ 2002-10-16 10:59 ` Dale Johannesen 2002-10-16 11:30 ` Geert Bosch 1 sibling, 1 reply; 14+ messages in thread From: Dale Johannesen @ 2002-10-16 10:59 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc On Tuesday, October 15, 2002, at 06:32 PM, Geert Bosch wrote: > a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address > 9404. > I guess this refers to code like: > addis r9,r31,ha16( > L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- > L42$pb) > lwz > r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- > L42$pb)(r9) Another possibility is that L_system__soft_links__get_jmpbuf_address$non_lazy_ptr is not defined. In either case I'd expect to see an "undefined symbol" message from the assembler though. If neither of those is it, send me a .s file and I'll figure it out. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-16 10:59 ` Dale Johannesen @ 2002-10-16 11:30 ` Geert Bosch 2002-10-16 11:48 ` Dale Johannesen 0 siblings, 1 reply; 14+ messages in thread From: Geert Bosch @ 2002-10-16 11:30 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc On Wednesday, Oct 16, 2002, at 13:12 America/New_York, Dale Johannesen wrote: > Another possibility is that > L_system__soft_links__get_jmpbuf_address$non_lazy_ptr > is not defined. In either case I'd expect to see an "undefined symbol" > message from the assembler though. If neither of those is it, send me > a .s file and I'll figure it out. It's defined in the .data segment, while the reference is in the .code segment. I can see how this wouldn't work... -Geert ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-16 11:30 ` Geert Bosch @ 2002-10-16 11:48 ` Dale Johannesen 2002-10-16 13:14 ` Geert Bosch 0 siblings, 1 reply; 14+ messages in thread From: Dale Johannesen @ 2002-10-16 11:48 UTC (permalink / raw) To: Geert Bosch; +Cc: Dale Johannesen, gcc On Wednesday, October 16, 2002, at 10:37 AM, Geert Bosch wrote: > > On Wednesday, Oct 16, 2002, at 13:12 America/New_York, Dale Johannesen > wrote: >> Another possibility is that >> L_system__soft_links__get_jmpbuf_address$non_lazy_ptr >> is not defined. In either case I'd expect to see an "undefined >> symbol" >> message from the assembler though. If neither of those is it, send me >> a .s file and I'll figure it out. > > It's defined in the .data segment, while the reference is in the .code > segment. I can see how this wouldn't work... No, that is supposed to be OK. non_lazy_ptr's are used for references to the address of a function (pointer-to-function) like this: extern int (*f)(int (*)()); main() { (*f)(f); } .text .... _main: .... bcl 20,31,L1$pb L1$pb: .... addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb) lwz r11,lo16(L_f$non_lazy_ptr-L1$pb)(r9) addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb) lwz r9,lo16(L_f$non_lazy_ptr-L1$pb)(r9) lwz r0,0(r11) lwz r3,0(r9) mr r12,r0 mtctr r12 bctrl .... .data .non_lazy_symbol_pointer L_f$non_lazy_ptr: .indirect_symbol _f So what's different about yours? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problems building GNAT on OS X with top-of-tree 2002-10-16 11:48 ` Dale Johannesen @ 2002-10-16 13:14 ` Geert Bosch 0 siblings, 0 replies; 14+ messages in thread From: Geert Bosch @ 2002-10-16 13:14 UTC (permalink / raw) To: Dale Johannesen; +Cc: gcc On Wednesday, Oct 16, 2002, at 13:47 America/New_York, Dale Johannesen wrote: > No, that is supposed to be OK. non_lazy_ptr's are used for > references to the address of a function (pointer-to-function) like > this: > > extern int (*f)(int (*)()); > main() { > (*f)(f); > } > > .text .... > _main: .... > bcl 20,31,L1$pb > L1$pb: .... > addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb) > lwz r11,lo16(L_f$non_lazy_ptr-L1$pb)(r9) > addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb) > lwz r9,lo16(L_f$non_lazy_ptr-L1$pb)(r9) > lwz r0,0(r11) > lwz r3,0(r9) > mr r12,r0 > mtctr r12 > bctrl > .... > .data > .non_lazy_symbol_pointer > L_f$non_lazy_ptr: > .indirect_symbol _f > > So what's different about yours? It seems to be the same. It doesn't help that the assembly message seems to refer to a location in the output file, which is not written to disk. Anyway, I'll send you the a-except.s file in a private email. Thanks for your help! -Geert .text ... L42$pb: ... addis r9,r31,ha16( L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-L42$pb) lwz r9,lo16( L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-L42$pb)(r9) lwz r9,0(r9) mtctr r9 bctrl ... .data ... .non_lazy_symbol_ptr ... L_system__soft_links__get_jmpbuf_address$non_lazy_ptr: .indirect_symbol _system__soft_links__get_jmpbuf_address .long 0 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-10-17 22:22 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E5B21272-E13A-11D6-B07C-000393D76DAA@apple.com> 2002-10-16 13:28 ` Problems building GNAT on OS X with top-of-tree Geert Bosch 2002-10-16 15:00 ` Dale Johannesen 2002-10-17 14:52 ` Geert Bosch 2002-10-17 15:00 ` Dale Johannesen 2002-10-17 15:02 ` Dale Johannesen 2002-10-17 15:22 ` Geoffrey Keating 2002-10-17 17:06 ` Dale Johannesen 2002-10-17 20:59 ` Geoffrey Keating 2002-10-15 21:08 Geert Bosch 2002-10-16 10:43 ` Dale Johannesen 2002-10-16 10:59 ` Dale Johannesen 2002-10-16 11:30 ` Geert Bosch 2002-10-16 11:48 ` Dale Johannesen 2002-10-16 13:14 ` Geert Bosch
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).