|
From: Jeremy F. <je...@go...> - 2004-01-08 21:06:46
Attachments:
archdep.patch
|
I've been thinking about how to rearrange the source tree to handle multiple OS and CPU combinations. I'm basing my thinking from looking at Doug's FreeBSD port, and Dirk's initial cut at an arch/ directory. It looks to me that there's a lot more in common between FreeBSD and Linux than I would have hoped for; almost all of vg_syscalls and vg_signals is intact, and vg_libpthread is mostly just syntactic changes rather than anything of substance. It would be really nice to put all that common stuff into a common place, to try and cut down on duplication. I'd also like to minimise #ifdefs in shared code. To this end, I think we'll need a number of arch directories: i386-linux machine-specific linux stuff i386-freebsd machine-specific freebsd stuff common-linux general linux stuff common-freebsd general freebsd stuff i386-common OS-independent i386 stuff common-unix things common to Unix-like systems (I decided to go with CPU names like autoconf/uname -i uses) So far, i386-linux/freebsd has things like vg_syscall.S, and the various very machine-dependent parts of ume. Later it will get things like the details of how to get/set syscall args for vg_syscalls.c, signal restart, etc. Also syscall numbering, and CPU-specific syscalls (LDT stuff, etc). common-linux/freebsd will probably get most of the rest of vg_signals where they differ, and probably most of the OS-specific parts of vg_syscalls.c i386-common will ultimately get most of vg_to/from_ucode.c. common-unix will get all the really generic syscall handling (things like read/write/exit/fork/exec, etc). I'm attaching my patch-in-progress. This is all still an experiment, so if it doesn't work out, I'm happy to throw it away. But I'd like to get something like this in place as I merge the FreeBSD port (or before, and merge FreeBSD into it). Comments? Thoughts? BTW: I put some stuff in the Makefile.am files which doesn't look good, and surely can't be right - there seems to be a lot of duplication. How can I fix this? Maybe something to do with aclocal? J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-08 21:18:07
|
On Thu, 8 Jan 2004, Jeremy Fitzhardinge wrote: > To this end, I think we'll need a number of arch directories: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff > i386-common OS-independent i386 stuff > common-unix things common to Unix-like systems > > (I decided to go with CPU names like autoconf/uname -i uses) Sounds ok to me. One comment: do we need the arch/ directory? I prefer flat, wide directory structures to narrow, deep ones. Eg. we don't have a tools/ directory containing all the tool-specific directories. N |
|
From: Dirk M. <dm...@gm...> - 2004-01-08 21:31:36
|
On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure how "stable" uname -i is going to be (or if the next release of gentoo hyperpatched will return i586 somewhen), and it didn't really save any code as far as I can see. > if it doesn't work out, I'm happy to throw it away. But I'd like to get > something like this in place as I merge the FreeBSD port (or before, and > merge FreeBSD into it). Yeah, thats what I started to do here locally already. > BTW: I put some stuff in the Makefile.am files which doesn't look good, > and surely can't be right - there seems to be a lot of duplication. How > can I fix this? Maybe something to do with aclocal? I think it should be handled with AC_SUBSTs, seems the cleanest solution to me. regarding Nicholas' question: I think putting all those nasty things in an arch/ subdir is the best solution, since we're going to have many subdirs and the extra subdir allows a very neat linking-together of the xxx-common and the common-xxx convenience libs into something that is then used for the coregrind targets. Dirk |
|
From: Doug R. <df...@nl...> - 2004-01-08 22:09:18
|
On Thu, 2004-01-08 at 21:31, Dirk Mueller wrote: > On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > > > i386-linux machine-specific linux stuff > > i386-freebsd machine-specific freebsd stuff > > common-linux general linux stuff > > common-freebsd general freebsd stuff > > yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure > how "stable" uname -i is going to be (or if the next release of gentoo > hyperpatched will return i586 somewhen), and it didn't really save any code > as far as I can see. If you are intending to name the instruction set rather than some specific implementation of it, I think intel likes it to be called 'ia32' these days. Having said that, 'i386' is used almost universally as a name for this architecture. |
|
From: Jeremy F. <je...@go...> - 2004-01-08 22:42:29
|
On Thu, 2004-01-08 at 13:31, Dirk Mueller wrote: > On Thursday 08 January 2004 22:04, Jeremy Fitzhardinge wrote: > > > i386-linux machine-specific linux stuff > > i386-freebsd machine-specific freebsd stuff > > common-linux general linux stuff > > common-freebsd general freebsd stuff > > yes, common is needed. is there any need to rename x86 to i386 ? I'm not sure > how "stable" uname -i is going to be (or if the next release of gentoo > hyperpatched will return i586 somewhen), and it didn't really save any code > as far as I can see. Well, i386 seems to be well accepted as the formal name for the architecture. I was a bit concerned that x86 might be ambigious with respect to x86-64 (if that's the proper architecture name). uname -i is supposed to return a generic CPU identifier; uname -m returns something more model-specific (i686). J |
|
From: Johan R. <jry...@ni...> - 2004-01-09 08:35:36
|
Jeremy Fitzhardinge <je...@go...> wrote:
: To this end, I think we'll need a number of arch directories:
: i386-linux machine-specific linux stuff
: i386-freebsd machine-specific freebsd stuff
: common-linux general linux stuff
: common-freebsd general freebsd stuff
: i386-common OS-independent i386 stuff
: common-unix things common to Unix-like systems
Why not go with a directory structure that looks like the one
in for example glibc? Example:
unix/ things common to Unix-like systems
unix/linux/ general linux stuff
unix/linux/i386 machine-specific linux stuff
...
i386/ OS-independent i386 stuff
Of course, in glibc all these dirs are located in sysdeps/
I think the "common" suffix and prefix make it too messy.
And why not "unix-common" instead of "common-unix"? i386-linux
vs linux-i386?
--
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/
|
|
From: Jeremy F. <je...@go...> - 2004-01-09 08:48:38
|
On Fri, 2004-01-09 at 00:35, Johan Rydberg wrote: > Why not go with a directory structure that looks like the one > in for example glibc? Because I can never work out how glibc actually builds itself, and I don't want the directory tree to get too deep. > Of course, in glibc all these dirs are located in sysdeps/ > I think the "common" suffix and prefix make it too messy. > And why not "unix-common" instead of "common-unix"? i386-linux > vs linux-i386? Well, autoconf seems to use the form CPU-OS; common-unix means "any cpu, unixish OS". J |
|
From: Johan R. <jry...@ni...> - 2004-01-09 10:46:28
|
Jeremy Fitzhardinge <je...@go...> wrote: : Because I can never work out how glibc actually builds itself, I think it adds all the directories to the VPATH, with the more specific ones ordered first. : and I don't want the directory tree to get too deep. Good argument, but I still think the "glibc way" is more logical, and actually, much more good looking. : Well, autoconf seems to use the form CPU-OS; common-unix means "any cpu, : unixish OS". It's true that autoconf uses that form, but I see no real reason to keep the common- prefix at all. Why not simply "unix" ? -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net | http://www.nongnu.org/guss/ Playing A-Skills and Krafty Kuts - Tricka Technology |
|
From: Julian S. <js...@ac...> - 2004-01-09 09:13:25
|
> rather than anything of substance. It would be really nice to put all > that common stuff into a common place, to try and cut down on > duplication. I'd also like to minimise #ifdefs in shared code. Definitely. Zero ifdefs is a worthy goal. I've seen maintenance nightmares caused by ifdef trees. > To this end, I think we'll need a number of arch directories: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff > i386-common OS-independent i386 stuff > common-unix things common to Unix-like systems So if a PPC port was done, the ppc insn decoder/emitters would go in ppc-common, and then ppc-linux would hold the glue for that particular (arch, OS) pair? Sounds ok to me. Are there any problems now stopping us using C++ ? We'd have to connect new/delete to our internal memory manager, but that's doable, no? J |
|
From: Jeremy F. <je...@go...> - 2004-01-09 17:30:17
|
On Fri, 2004-01-09 at 01:15, Julian Seward wrote: > So if a PPC port was done, the ppc insn decoder/emitters > would go in ppc-common, and then ppc-linux would hold the > glue for that particular (arch, OS) pair? Sounds ok to me. Yup. > Are there any problems now stopping us using C++ ? We'd > have to connect new/delete to our internal memory manager, > but that's doable, no? Should be OK, in principle. Haven't tested it. J |