|
From: Nicholas N. <nj...@ca...> - 2004-08-25 12:36:35
|
Hi, I've rejigged my file/dir structure proposal, and started reshaping Paul's x86-abstraction patch accordingly. You can grab see the basics in a tarball at www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 and the diff (which is hard to read and doesn't account for the new files and file renamings) is at www.cl.cam.ac.uk/~njn25/vg-arch.diff I've left lots of Paul's patch out; this tarball contains just enough of it to show how the structure works. We've discussed arch-, os- and platform-specific code; this version only contains arch- abstraction, which is enough to see how things work. So, for example, there is stuff in coregrind/x86/ but there is no coregrind/linux/ or coregrind/x86-linux/ directories yet. Note that a few header filenames have changed, notably: vg_include.h --> core.h vg_skin.h --> tool.h vg_constants.h --> core_asm.h vg_constants_skin.h --> tool_asm.h And there are various new headers. include/x86/ is new as well. As for how these proposed file renamings would be done in CVS, I think just cvs removing then cvs adding them under the new names would do. We'd lose the direct log history, but it would still be available under the old names. We've already had this happen once when vg_skin.h became vg_skin.h.base, and it's only another four files. The alternatives (either hacking the repository, or switching to something better than CVS) are sufficiently painful/controversial in the short-term that I'd prefer this, which has the virtue of being able to be done easily and quickly. I ended up using -I instead of symlinks to select the right $ARCH/ directory, because that ended up being the easiest to get right. I include below a revised description of how it works; it has significant differences to my first version, and is hopefully substantially clearer, so I recommend reading it again. Note that this tarball includes changes involved with factoring out the common Makefile.am parts into multiple files. These are currently in the top-level directory, perhaps they could go in a dedicated directory to reduce clutter. I plan to separate that part of the patch out and commit it first, probably after 2.2.0 is released. After that, once we've agreed on the exact file/dir structure, I'd like to start the restructuring in earnest (starting with completing the changes in Paul's patch) since all arch port work depends on this (eg. Paul's PPC port, my nascent x86-64 port). All feedback welcome. Thanks. N Proposal -------- Terminology: A "platform" is a specific $ARCH/$OS pair. For every arch and OS, there will be 4 code parts, in order of genericity: 1. some generic code 2a. some arch-specific, OS-independent code (aka $ARCH, arch) 2b. some arch-independent, OS-specific code (aka $OS, os) 3. some platform-specific code (aka $ARCH-$OS, arch-os) 2a, 2b and 3 are all "non-generic". The keys ideas are: - to very carefully identify which category all code belongs to - to minimise the interface between generic and non-generic code - to minimise code duplication by pushing code into the most generic code part possible Abstract directory structure (where the right hand side shows what fns/vars/macros would go in each file): valgrind/ memcheck/ cachegrind/ # etc, other tools include/ tool.h (was vg_skin.h) tool_asm.h (was vg_constants_skin.h) x86/ tool_arch.h ARCH_STACK_POINTER(?), REGPARM, FIRST_ARCH_REG linux/ x86-linux/ unistd.h? coregrind/ core.h (was vg_include.h) includes decls of arch/OS/platform-specific fns/vars, eg. VGA_(load_state)(), IR decode/encode decls, VG_(do_syscall)(), VG_(arch_deliver_signal)()(?) core_asm.h (was vg_constants.h) x86/ (all contents become libarch.a) # interface core_arch.h arch_thread_t core_arch_asm.h VG_PATCHME_CALLSZ, VG_CODE_OFFSET, INSTR_MIN_SIZE # implementation (exact file names don't matter) x86.h VG_SIZE_OF_SSESTATE(?), VG_(do_useseg)() decl, VG_(helper_*) decl, VGOFF_(m_eax) x86_state.c VG_(arch_load_state)() definition, VG_(helper_*) def VGOFF_(m_eax) def x86_asm.S x86_ldt.c VG_(do_useseg)() def x86_to_IR.c # x86 disassembly to IR stuff x86_from_IR.c # x86 IR codegen stuff linux/ #interface core_os.h core_os_asm.h # implementation vg_kerneliface.h types generic for all Linux platforms(?) etc. x86-linux/ # interface core_platform.h ARCH_SYSCALL_NUM core_platform_asm.h # implementation x86-linux_asm.S VG_(do_syscall)() definition x86-linux_signal.c VG_(arch_deliver_signal)() definition(?) x86-linux_vki.h x86/Linux-specific kernel types[or interface?] Interfacing .c/.S files with .h files: - all core C files include core.h - all core asm files include core_asm.h - all tool C files include tool.h - all tool asm files include tool_asm.h - The header hierarchy itself is based around the following rules: - core headers include tool headers - generic headers include arch/OS/platform headers - C headers include asm headers This gives the following hierarchy (only showing 'arch' headers, not 'os' or 'platform' headers), where arrows indicate inclusion: (tool_arch_asm.h?) <------- core_arch_asm.h ^ ^ ^ ^ / \ / \ / \ / \ tool_asm.h <---\---------- core_asm.h \ ^ \ ^ \ \ tool_arch.h <---------\---- core_arch.h \ ^ \ ^ \ / \ / \ / \ / tool.h <------------------ core.h (This is sufficiently complex that clear names are important; this is why I'm suggesting changing the old names vg_skin.h, vg_constants.h, etc, which make it much harder to see what the headers contain.) Note that core.h contains the *declarations* of arch-specific functions and variables. (The functions/variables are *defined* within $VG_ARCH/.) However, arch-specific macros and types cannot go into core.h, because there is no separation between declaration and definition for macros/types, so they instead go into $VG_ARCH/core_arch.h. tool_arch_asm.h is in parens because I'm not aware of any arch-specific asm macros needed by tools, and so we don't have it at the moment. Actions: - Config-time setup sets $VG_ARCH, $VG_OS, $VG_PLATFORM - using -I with $VG_ARCH et al to select the right arch/OS/platform headers - stage2 built from generic .o files + $VG_ARCH/libarch.a, $VG_OS/libos.a, $VG_PLATFORM/libplatform.a Note that each part's .h is necessarily split into defs and macros; the defs .h can be shared by all sub-dirs, whereas each sub-dir has to provide its own version of every macro. This is because functions/variables can be defined/declared in different places, but macros can't. This is the "minimise duplication" principle at work. At the moment, there is no special treatment of stuff shared between multiple Unixes, or Elf stuff shared between multiple platforms. I imagine having separate unix/ and elf/ subdirs would be fine, and the relevant libarch.a/libos.a/libplatform.a files could be built using any needed parts in them. For tools that need to do non-generic things (which should be avoided as much as possible, but may be inevitable in small amounts, esp. for Memcheck) parts of the structure can be mirrored as necessary within the tool/ (eg. memcheck/) directory. |
|
From: Paul M. <pa...@sa...> - 2004-08-28 08:19:42
|
Nicholas Nethercote writes: > I've rejigged my file/dir structure proposal, and started reshaping Paul's > x86-abstraction patch accordingly. You can grab see the basics in a > tarball at > > www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 Looks good, but you seem to have left out Makefile.all.am, Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. The rest of your proposal looks fine to me. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-28 14:09:23
|
On Sat, 28 Aug 2004, Paul Mackerras wrote: >> I've rejigged my file/dir structure proposal, and started reshaping Paul's >> x86-abstraction patch accordingly. You can grab see the basics in a >> tarball at >> >> www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 > > Looks good, but you seem to have left out Makefile.all.am, > Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. Yes... strange that "make distcheck" didn't pick that up. Hmm. I've fixed it up and updated the tarball. > The rest of your proposal looks fine to me. Great, thanks for looking at it. Other comments are still welcome. N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-31 22:41:43
|
On Sat, 28 Aug 2004, Paul Mackerras wrote: >> I've rejigged my file/dir structure proposal, and started reshaping Paul's >> x86-abstraction patch accordingly. You can grab see the basics in a >> tarball at >> >> www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 > > Looks good, but you seem to have left out Makefile.all.am, > Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. > > The rest of your proposal looks fine to me. Does anyone else have any comments about/objections to my proposal? I'd like to start moving it in. Thanks. N |
|
From: Julian S. <js...@ac...> - 2004-09-01 09:32:34
|
> >> www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 > > > > Looks good, but you seem to have left out Makefile.all.am, > > Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. > > > > The rest of your proposal looks fine to me. > > Does anyone else have any comments about/objections to my proposal? I'd > like to start moving it in. I just looked through www.cl.cam.ac.uk/~njn25/vg-arch.diff. It looks good to me; carry on, I say. One comment: I see a lot of places where a struct called "arch" got introduced: tst->sh_eax = val; becomes tst->arch.sh_eax = val; and I wonder if it would be wiser to call this "guest." than "arch." in view of the fact that one day we may be in a world where the guest and host architectures are not the same, in which case plain .arch is confusing. Is that possible? I volunteer to make emacs do global search-n-replace if that helps. J |
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 22:03:01
|
On Wed, 1 Sep 2004, Julian Seward wrote: > I just looked through www.cl.cam.ac.uk/~njn25/vg-arch.diff. It looks > good to me; carry on, I say. Righto! Thanks for looking. > One comment: I see a lot of places where a struct called "arch" got > introduced: > > tst->sh_eax = val; > becomes > tst->arch.sh_eax = val; > > and I wonder if it would be wiser to call this "guest." than "arch." > in view of the fact that one day we may be in a world where the guest > and host architectures are not the same, in which case plain .arch is > confusing. Is that possible? I volunteer to make emacs do global > search-n-replace if that helps. I sympathise with the reasoning, but until guest != host is actually working (if it ever does), I think calling it "guest" would be confusing. Changing the name later, if necessary, won't be difficult. So I'll stick with "arch". N |