* arm questions @ 1999-04-15 10:38 Doug Evans 1999-04-15 11:01 ` Ian Lance Taylor 0 siblings, 1 reply; 15+ messages in thread From: Doug Evans @ 1999-04-15 10:38 UTC (permalink / raw) To: bfd Two random questions. 1) elfarm-oabi.c uses USE_RELA elfarm-nabi.c uses USE_REL That seems rather backwards, doesn't it? I'd expect a new version of an abi to switch from USE_REL to USE_RELA, but not the other way around. [not that it can be changed, but rather ... why the switch?] 2) Whats the R_ARM_THM_XPC22 reloc for? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 10:38 arm questions Doug Evans @ 1999-04-15 11:01 ` Ian Lance Taylor 1999-04-15 11:31 ` Scott Bambrough ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Ian Lance Taylor @ 1999-04-15 11:01 UTC (permalink / raw) To: devans; +Cc: bfd Date: Thu, 15 Apr 1999 10:38:25 -0700 From: Doug Evans <devans@cygnus.com> Two random questions. 1) elfarm-oabi.c uses USE_RELA elfarm-nabi.c uses USE_REL That seems rather backwards, doesn't it? I'd expect a new version of an abi to switch from USE_REL to USE_RELA, but not the other way around. [not that it can be changed, but rather ... why the switch?] This is my understanding of the situation. If anybody knows that I am wrong, please correct me. The ARM ELF situation is a mess because there were two separate implementations. Some folks in England put together ARM GNU/Linux, but they took a very long time to get the copyright stuff done. For some reason that I do not know, that implementation used REL rather than RELA relocs. In the meantime, Cygnus implemented ARM ELF, using RELA relocs. It's obviously desirable to have a single ARM ELF ABI, and the best choice is probably the one currently being used for GNU/Linux. Therefore, when we straightened out the copyright situation, we dumped the Cygnus RELA implementation in favour of the GNU/Linux REL implementation. 2) Whats the R_ARM_THM_XPC22 reloc for? I dunno. Philip Blundell is on the list. Phil, do you know? Ian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 11:01 ` Ian Lance Taylor @ 1999-04-15 11:31 ` Scott Bambrough 1999-04-15 11:47 ` Ian Lance Taylor 1999-04-15 13:10 ` arm questions H.J. Lu 1999-04-15 13:36 ` Philip Blundell 2 siblings, 1 reply; 15+ messages in thread From: Scott Bambrough @ 1999-04-15 11:31 UTC (permalink / raw) To: bfd Ian Lance Taylor wrote: > > Date: Thu, 15 Apr 1999 10:38:25 -0700 > From: Doug Evans <devans@cygnus.com> > > Two random questions. > > 1) > elfarm-oabi.c uses USE_RELA > elfarm-nabi.c uses USE_REL > That seems rather backwards, doesn't it? > I'd expect a new version of an abi to switch from USE_REL to USE_RELA, > but not the other way around. > [not that it can be changed, but rather ... why the switch?] > > This is my understanding of the situation. If anybody knows that I am > wrong, please correct me. > > The ARM ELF situation is a mess because there were two separate > implementations. > > Some folks in England put together ARM GNU/Linux, but they took a very > long time to get the copyright stuff done. For some reason that I do > not know, that implementation used REL rather than RELA relocs. Actually Phil is in England, Pat Beirne and I are in Canada. And that very long copyright time was due entirely to Corel's legal department. They were a pain in the ass. We chose REL because we did not need the addend. In hindsight I would choose RELA. We did this work over a period of about 6 months when we brought up gcc, binutils, gdb and glibc on the NetWinder. > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. Something of which we were entirely unaware of at the time, otherwise we would have attempted to collaborate in a closer fashion. > It's obviously desirable to have a single ARM ELF ABI, and the best > choice is probably the one currently being used for GNU/Linux. > Therefore, when we straightened out the copyright situation, we dumped > the Cygnus RELA implementation in favour of the GNU/Linux REL > implementation. I don't know about better. Cygnus does pretty good work. It probably has a larger installed base ATM, as the GNU/Linux implementation is used by HJ Lu's 2.9.1.0.xx releases of binutils. I think most of the ARM community uses this rather than the GAS2 snapshots. > Whats the R_ARM_THM_XPC22 reloc for? The docs say it is a Thumb BLX pair. It is a two byte Thumb instruction. It is a relocateable branch instruction, where bits 0-10 encode the 11 most significant bits of the branch offset, and bits 0-10 of the next instruction word encode the least significant bits of the branch offset. There is also a note about it being provisional. The least significant bit of the branch offset must be zero. Scott Bambrough ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 11:31 ` Scott Bambrough @ 1999-04-15 11:47 ` Ian Lance Taylor 1999-04-15 13:29 ` H.J. Lu 0 siblings, 1 reply; 15+ messages in thread From: Ian Lance Taylor @ 1999-04-15 11:47 UTC (permalink / raw) To: scottb; +Cc: bfd Date: Thu, 15 Apr 1999 14:49:16 -0400 From: Scott Bambrough <scottb@corelcomputer.com> Actually Phil is in England, Pat Beirne and I are in Canada. Oops--sorry. We chose REL because we did not need the addend. In hindsight I would choose RELA. For the benefit of anybody who is considering an ELF port, please always use RELA relocs rather than REL relocs. REL relocs work OK for processors with very simple relocation needs, like an i386 or m68k. For a RISC processor, they are a real pain. You always need to support an addend which can support your entire address space, in order to handle code like this: char a[10000]; int foo () { return a[9999]; } This ought to turn into a reference to the symbol a + 9999, so you need an addend which can hold a value of 9999, or you get inefficient code. > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. Something of which we were entirely unaware of at the time, otherwise we would have attempted to collaborate in a closer fashion. I now recall that I dropped the ball on this one. I saw the request for the ARM ELF work come in to Cygnus, but I didn't manage to figure out that it was for a different ABI than the one in H.J.'s snapshots. Ian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 11:47 ` Ian Lance Taylor @ 1999-04-15 13:29 ` H.J. Lu 1999-04-15 13:59 ` Ian Lance Taylor 0 siblings, 1 reply; 15+ messages in thread From: H.J. Lu @ 1999-04-15 13:29 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: scottb, bfd > > Date: Thu, 15 Apr 1999 14:49:16 -0400 > From: Scott Bambrough <scottb@corelcomputer.com> > > Actually Phil is in England, Pat Beirne and I are in Canada. > > Oops--sorry. > > We chose REL because we did not need the addend. In hindsight I > would choose RELA. > > For the benefit of anybody who is considering an ELF port, please > always use RELA relocs rather than REL relocs. REL relocs work OK for > processors with very simple relocation needs, like an i386 or m68k. > For a RISC processor, they are a real pain. You always need to > support an addend which can support your entire address space, in > order to handle code like this: > char a[10000]; > int foo () { return a[9999]; } > This ought to turn into a reference to the symbol a + 9999, so you > need an addend which can hold a value of 9999, or you get inefficient > code. Ok. You are saying RELA is better than REL. Does it make any senses to use RELA for relocatable object and allow REL for excutable and shared objects? > > > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. > > Something of which we were entirely unaware of at the time, otherwise we would > have attempted to collaborate in a closer fashion. > > I now recall that I dropped the ball on this one. I saw the request > for the ARM ELF work come in to Cygnus, but I didn't manage to figure > out that it was for a different ABI than the one in H.J.'s snapshots. > If RELA is really desired, can ARM/Linux switch to RELA with a different soname? Binaries using REL should still run ok, just like what we did to libc 5 on x86. -- H.J. Lu (hjl@gnu.org) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 13:29 ` H.J. Lu @ 1999-04-15 13:59 ` Ian Lance Taylor 1999-04-15 14:15 ` Mixing REL and RELA H.J. Lu 0 siblings, 1 reply; 15+ messages in thread From: Ian Lance Taylor @ 1999-04-15 13:59 UTC (permalink / raw) To: hjl; +Cc: bfd From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 13:28:50 -0700 (PDT) Ok. You are saying RELA is better than REL. Does it make any senses to use RELA for relocatable object and allow REL for excutable and shared objects? It is possible in principle. In the general case, it is hard. ELF permits a shared library to be compiled normally, not PIC. In such a case, you have to use arbitrary relocations in the shared library. The dynamic linker then runs into the same addend problems as the program linker does. For a PIC shared library, there is normally only a very restricted set of dynamic relocs: a GOT reloc, a JMP reloc, a RELATIVE reloc, and perhaps a few relocs in the .data section. All of these relocs can normally be easily represented using REL relocs. Since in principle the dynamic linker can handle both REL and RELA relocs in the same object, it would be possible in principle to add this optimization for an ELF target which used RELA relocs. I think it would probably be more immediately effective to focus efforts on reducing the total number of dynamic relocations in libc. For example, it has scads of RELATIVE relocs; why? It has GLOB_DAT and JUMP_SLOT relocs for what appear to be internal symbols; it may be possible to eliminate these. > > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. > > Something of which we were entirely unaware of at the time, otherwise we would > have attempted to collaborate in a closer fashion. > > I now recall that I dropped the ball on this one. I saw the request > for the ARM ELF work come in to Cygnus, but I didn't manage to figure > out that it was for a different ABI than the one in H.J.'s snapshots. > If RELA is really desired, can ARM/Linux switch to RELA with a different soname? Binaries using REL should still run ok, just like what we did to libc 5 on x86. If REL works now, there is probably no reason to switch to RELA. The only reason I can think of would be if the compiler can gain an advantage by splitting instructions which require relocations. It is sometime possible to make that work with REL instructions anyhow. It would also be possible for the linker to support REL and RELA relocations simultaneously, so there would be no need for a big cutover. We would just change gas to start generating RELA relocations, and then after a while we could throw away the REL support. But I don't see a reason to do that if the code works now. Ian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Mixing REL and RELA 1999-04-15 13:59 ` Ian Lance Taylor @ 1999-04-15 14:15 ` H.J. Lu 1999-04-15 14:21 ` Ian Lance Taylor 0 siblings, 1 reply; 15+ messages in thread From: H.J. Lu @ 1999-04-15 14:15 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: bfd > If REL works now, there is probably no reason to switch to RELA. The > only reason I can think of would be if the compiler can gain an > advantage by splitting instructions which require relocations. It is > sometime possible to make that work with REL instructions anyhow. > > It would also be possible for the linker to support REL and RELA > relocations simultaneously, so there would be no need for a big > cutover. We would just change gas to start generating RELA > relocations, and then after a while we could throw away the REL > support. > > But I don't see a reason to do that if the code works now. > Does the linker support mixing REL and RELA on any targets? How CPU depedent is this support? It may be useful to CPUs other than ARM. -- H.J. Lu (hjl@gnu.org) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Mixing REL and RELA 1999-04-15 14:15 ` Mixing REL and RELA H.J. Lu @ 1999-04-15 14:21 ` Ian Lance Taylor 1999-04-15 14:28 ` H.J. Lu 0 siblings, 1 reply; 15+ messages in thread From: Ian Lance Taylor @ 1999-04-15 14:21 UTC (permalink / raw) To: hjl; +Cc: bfd From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 14:15:54 -0700 (PDT) > If REL works now, there is probably no reason to switch to RELA. The > only reason I can think of would be if the compiler can gain an > advantage by splitting instructions which require relocations. It is > sometime possible to make that work with REL instructions anyhow. > > It would also be possible for the linker to support REL and RELA > relocations simultaneously, so there would be no need for a big > cutover. We would just change gas to start generating RELA > relocations, and then after a while we could throw away the REL > support. > > But I don't see a reason to do that if the code works now. Does the linker support mixing REL and RELA on any targets? How CPU depedent is this support? It may be useful to CPUs other than ARM. I had this working at least for a little while for the 64 bit MIPS ELF target, where the ABI from SGI requires it. However, that target never really worked, so I don't know how well mixing REL and RELA works. The support I wrote for MIPS is CPU dependent; the code is in elf64-mips.c. But I can't think of any reason why it has to be there. Most relocation processing is CPU dependent anyhow, probably too much so. However, I would discourage mixing REL and RELA in object files. That's just added complexity for no real benefit that I can see. Ian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Mixing REL and RELA 1999-04-15 14:21 ` Ian Lance Taylor @ 1999-04-15 14:28 ` H.J. Lu 0 siblings, 0 replies; 15+ messages in thread From: H.J. Lu @ 1999-04-15 14:28 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: bfd > > I had this working at least for a little while for the 64 bit MIPS ELF > target, where the ABI from SGI requires it. However, that target > never really worked, so I don't know how well mixing REL and RELA > works. > > The support I wrote for MIPS is CPU dependent; the code is in > elf64-mips.c. But I can't think of any reason why it has to be there. > > Most relocation processing is CPU dependent anyhow, probably too much > so. > > However, I would discourage mixing REL and RELA in object files. > That's just added complexity for no real benefit that I can see. > Unfortunately some ABIs require that. -- H.J. Lu (hjl@gnu.org) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 11:01 ` Ian Lance Taylor 1999-04-15 11:31 ` Scott Bambrough @ 1999-04-15 13:10 ` H.J. Lu 1999-04-15 13:45 ` Ian Lance Taylor 1999-04-15 13:36 ` Philip Blundell 2 siblings, 1 reply; 15+ messages in thread From: H.J. Lu @ 1999-04-15 13:10 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: devans, bfd > Some folks in England put together ARM GNU/Linux, but they took a very > long time to get the copyright stuff done. For some reason that I do > not know, that implementation used REL rather than RELA relocs. > > In the meantime, Cygnus implemented ARM ELF, using RELA relocs. > > It's obviously desirable to have a single ARM ELF ABI, and the best > choice is probably the one currently being used for GNU/Linux. > Therefore, when we straightened out the copyright situation, we dumped > the Cygnus RELA implementation in favour of the GNU/Linux REL > implementation. > While we are on RELA/REL, could someone kindly enough tell me the implementation and performance impacts between RELA and REL, on both static and dynamic objects? Thanks a lot. -- H.J. Lu (hjl@gnu.org) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 13:10 ` arm questions H.J. Lu @ 1999-04-15 13:45 ` Ian Lance Taylor 0 siblings, 0 replies; 15+ messages in thread From: Ian Lance Taylor @ 1999-04-15 13:45 UTC (permalink / raw) To: hjl; +Cc: bfd From: hjl@lucon.org (H.J. Lu) Date: Thu, 15 Apr 1999 13:10:12 -0700 (PDT) While we are on RELA/REL, could someone kindly enough tell me the implementation and performance impacts between RELA and REL, on both static and dynamic objects? I quote bfd/doc/bfdint.texi: In the absence of a supplement, it's easier to work with @samp{Rela} relocations. @samp{Rela} relocations will require more space in object files (but not in executables, except when using dynamic linking). However, this is outweighed by the simplicity of addend handling when using @samp{Rela} relocations. With @samp{Rel} relocations, the addend must be stored in the section contents, which makes relocateable links more complex. For example, consider C code like @code{i = a[1000];} where @samp{a} is a global array. The instructions which load the value of @samp{a[1000]} will most likely use a relocation which refers to the symbol representing @samp{a}, with an addend that gives the offset from the start of @samp{a} to element @samp{1000}. When using @samp{Rel} relocations, that addend must be stored in the instructions themselves. If you are adding support for a RISC chip which uses two or more instructions to load an address, then the addend may not fit in a single instruction, and will have to be somehow split among the instructions. This makes linking awkward, particularly when doing a relocateable link in which the addend may have to be updated. It can be done---the MIPS ELF support does it---but it should be avoided when possible. In short, it's much easier to get the implementation right when using RELA relocations. RELA relocations also permit more flexible handling of split instructions. When the addend has to be gathered together from two or more instructions, the linker has to be able to find them all, which makes it harder to duplicate some and even harder to move them around. This takes away flexibility from the compiler, which may want to be able to move the instructions around freely in order to fill delay slots and the like. A statically linked executable contains no relocation information, so there is no performance difference between REL and RELA relocations. A dynamically linked executable does contain relocation entries. A RELA relocation is 4 bytes larger than a REL relocation (8 bytes larger for a 64 bit target). A REL relocation is 8 bytes, a RELA relocation is 12 bytes (16 and 24 for a 64 bit target). I checked /lib/libc.so.6 on an i386 RedHat 5.2 GNU/Linux system. It has 1914 dynamic relocations. With REL relocations, that takes 15312 bytes, or 3 pages assuming a 4K page size as on the i386. With RELA relocations, it takes 22968 bytes, or 5 pages. So the cost of using RELA relocations is reading 2 disk pages from the cache each time a program is run. (The ix86 uses REL relocations, incidentally.) Actually, it's not so simple, because the dynamic linker does not have to process the jump table relocation entries each time. They can be handled lazily. However, most programs will force at least some jump table relocations to be processed, so it is likely that the dynamic linker will have to read all the dynamic relocations at some point. A complex program may conceivably have enough dynamic relocations to force an extra page to be read, but I doubt that is common. Ian ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 11:01 ` Ian Lance Taylor 1999-04-15 11:31 ` Scott Bambrough 1999-04-15 13:10 ` arm questions H.J. Lu @ 1999-04-15 13:36 ` Philip Blundell 1999-04-16 0:43 ` Lee Smith [not found] ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com> 2 siblings, 2 replies; 15+ messages in thread From: Philip Blundell @ 1999-04-15 13:36 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: devans, bfd, lee.smith >Some folks in England put together ARM GNU/Linux, but they took a very >long time to get the copyright stuff done. For some reason that I do >not know, that implementation used REL rather than RELA relocs. Yes, it was all a bit of a mess. In fact (for the benefit of anybody who actually wants the whole gory history) the original implementation that I hacked together for ARM GNU/Linux *did* use RELA relocs. Then Pat and Scott from Corel produced a rather more complete implementation (one that included PIC support) based on the i386 code and hence using REL, and that was the code base that we ended up using. In fact as far as Linux is concerned it probably wouldn't be an especially big deal to introduce RELA in parallel with REL if we wanted to. I think there were rumblings that the ARM SDT compiler was primarily using RELA, so we might end up doing it in order to be able to interwork with them. Our dynamic linker can be taught to handle binaries with an arbitrary mix of reloc types, I think, and I imagine binutils can be made to handle this too if it doesn't already. > 2) > Whats the R_ARM_THM_XPC22 reloc for? > >I dunno. Philip Blundell is on the list. Phil, do you know? Actually no. Thumb isn't really my area. I've sent a Cc of this mail to Lee Smith (who did the original assignment of reloc numbers if I remember right). Lee, any ideas? p. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-15 13:36 ` Philip Blundell @ 1999-04-16 0:43 ` Lee Smith 1999-04-16 3:21 ` Toshi Morita [not found] ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com> 1 sibling, 1 reply; 15+ messages in thread From: Lee Smith @ 1999-04-16 0:43 UTC (permalink / raw) To: Philip Blundell, Ian Lance Taylor; +Cc: devans, bfd At 09:36 PM 4/15/99 +0100, Philip Blundell wrote: [SNIP] >In fact as far as Linux is concerned it probably wouldn't be an especially >big deal to introduce RELA in parallel with REL if we wanted to. I think >there were rumblings that the ARM SDT compiler was primarily using RELA, No. ARM only uses REL. We see no advantage to RELA. However, our ELF linker (not yet released) handles RELA or any mix of REL and RELA (as the ELF standard seems to intend). AFAIK, Green Hills uses RELA only in its ARM ELF tool chain. >so we >might end up doing it in order to be able to interwork with them. Our dynamic >linker can be taught to handle binaries with an arbitrary mix of reloc types, >I think, and I imagine binutils can be made to handle this too if it doesn't >already. > >> 2) >> Whats the R_ARM_THM_XPC22 reloc for? >> >>I dunno. Philip Blundell is on the list. Phil, do you know? > >Actually no. Thumb isn't really my area. I've sent a Cc of this mail to Lee >Smith (who did the original assignment of reloc numbers if I remember right). >Lee, any ideas? Actually, it should be R_ARM_THM_XPC23. It applies to an Architecture V5 variant BL instruction. Consider it a placeholder for now. ---Lee ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: arm questions 1999-04-16 0:43 ` Lee Smith @ 1999-04-16 3:21 ` Toshi Morita 0 siblings, 0 replies; 15+ messages in thread From: Toshi Morita @ 1999-04-16 3:21 UTC (permalink / raw) To: bfd > >In fact as far as Linux is concerned it probably wouldn't be an especially > >big deal to introduce RELA in parallel with REL if we wanted to. I think > >there were rumblings that the ARM SDT compiler was primarily using RELA, > > No. ARM only uses REL. We see no advantage to RELA. However, our ELF > linker (not yet released) handles RELA or any mix of REL and RELA > (as the ELF standard seems to intend). > > AFAIK, Green Hills uses RELA only in its ARM ELF tool chain. > > >so we > >might end up doing it in order to be able to interwork with them. Our > dynamic > >linker can be taught to handle binaries with an arbitrary mix of reloc > types, > >I think, and I imagine binutils can be made to handle this too if it doesn't > >already. The BFD when configured for sh-elf supports both REL and RELA relocation types although sh-elf-gcc itself only uses REL. Toshi ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com>]
* Re: arm questions [not found] ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com> @ 1999-04-18 17:10 ` Doug Evans 0 siblings, 0 replies; 15+ messages in thread From: Doug Evans @ 1999-04-18 17:10 UTC (permalink / raw) To: Lee Smith; +Cc: bfd Lee.Smith@arm.com (Lee Smith) writes: > However, our ELF > linker (not yet released) handles RELA or any mix of REL and RELA > (as the ELF standard seems to intend). The ELF standard intends linkers to handle both? ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~1999-04-18 17:10 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-04-15 10:38 arm questions Doug Evans 1999-04-15 11:01 ` Ian Lance Taylor 1999-04-15 11:31 ` Scott Bambrough 1999-04-15 11:47 ` Ian Lance Taylor 1999-04-15 13:29 ` H.J. Lu 1999-04-15 13:59 ` Ian Lance Taylor 1999-04-15 14:15 ` Mixing REL and RELA H.J. Lu 1999-04-15 14:21 ` Ian Lance Taylor 1999-04-15 14:28 ` H.J. Lu 1999-04-15 13:10 ` arm questions H.J. Lu 1999-04-15 13:45 ` Ian Lance Taylor 1999-04-15 13:36 ` Philip Blundell 1999-04-16 0:43 ` Lee Smith 1999-04-16 3:21 ` Toshi Morita [not found] ` <3.0.5.32.19990416083918.0099b8a0.cygnus.local.bfd@mail1.bateman.arm.com> 1999-04-18 17:10 ` Doug Evans
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).