Subject: Re: CVS Repository Mirroring
To: BOUWSMA Beery <netbsd-user@netscum.dyndns.dk>
From: John Polstra <jdp@polstra.com>
List: current-users
Date: 02/17/2002 17:15:13
BOUWSMA Beery wrote:

[ezm3]
> 
> If someone tries to build this, like I did with -current, then it is
> required to have the following compatibility kernel option in your
> kernel, otherwise the cvsup binary will fail with `bad system call'
> 
> options         COMPAT_13       # NetBSD 1.3,
> 
> There's a sigprocmask call that needs this.
> 
> [...]
>   7148 cvsup    CALL  __sigaction14(0x1a,0xbfbfdae0,0xbfbfdaf8)
>   7148 cvsup    RET   __sigaction14 0
>   7148 cvsup    CALL  setitimer(0x1,0xbfbfdb50,0xbfbfdb60)
>   7148 cvsup    RET   setitimer 0
>   7148 cvsup    CALL  compat_13_sigprocmask13(0x2,0x2000000)
>   7148 cvsup    PSIG  SIGSYS SIG_DFL
>   7148 cvsup    NAMI  "cvsup.core"

Whoops, that's a bug.  I didn't realize NetBSD had expanded their
sigset_t type.  Ezm3 is still using the old sigset_t which is just a
single int.  Actually it's worse than that, since the ktrace output
above indicates mixed usages of the two versions.  I'm surprised it
works at all.

I'll make a note to fix this in the next release of ezm3.

> I can't see that COMPAT_14 and higher are needed (at least, it runs
> fine, though perhaps something I haven't run across might need it).

If you can think of any other significant changes to the data
structures exported by the kernel since the sigset_t change was made,
please let me know so I can check those too.

> I'd love to say that I was able to cross-compile to my NetBSD-sparc
> machine, but so far no luck, either with failures to malloc adequate
> memory or SIGBUS errors, so it's obvious I have no clue as to what I
> am trying to do, but I'll keep plugging away at it.

As you've probably figured out already, the code generator isn't the
biggest part of the work in doing a port.  The biggest part is porting
all of the interface (.i3) files which declare data structures and
function prototypes for all of the libc functions.  These Modula-3
declarations have to match up bit-for-bit with the corresponding C
declarations from /usr/include.  The areas to look at in the ezm3
sources are these directories:

    libs/m3core/src/unix/netbsd-1
    libs/m3core/src/runtime/NetBSD*

I'll append a somewhat cryptic crib sheet that I use to help me
remember how to do a port to a new platform.  Maybe you'll find it
useful.

John

Porting crib sheet for an imaginary port to FreeBSD 3.x:

Directories and files to create:

    libs/m3core/src/C/FreeBSD3
    libs/m3core/src/Csupport/FreeBSD3
    libs/m3core/src/runtime/FreeBSD3
    libs/m3core/src/unix/freebsd-3
    m3config/src/FreeBSD3

Files to edit:

    language/modula3/m3compiler/m3middle/src/Target.m3
    language/modula3/m3tools/m3gdb/gdb/ltconfig
    libs/libm3/src/random/m3makefile
    libs/m3core/src/float/m3makefile
    libs/m3core/src/runtime/m3makefile
    libs/m3core/src/time/POSIX/m3makefile
    libs/m3core/src/unix/m3makefile
    m3config/src/COMMON

To disable VM-synchronized GC:

    libs/m3core/src/runtime/FreeBSD3/RTMachine.i3
        Set VMHeap = FALSE

    libs/m3core/src/runtime/FreeBSD3/RTHeapDepC.c
        #ifdef out most of the file.

To add custom options for the bootstrap:

    language/modula3/m3compiler/m3bootstrap/src/m3makefile
        Search for ALPHA_OSF to see examples.

Special gcc config options:

    language/modula3/m3compiler/m3cc/src/m3makefile

GCC configure script:

    language/modula3/m3compiler/m3cc/gcc/configure

Other stuff:

    You must build and install the new m3middle, m3build, and m3ship
    before you can make a bootstrap.

    Use gmake.

    GCC build wants byacc.  Sometimes you can finesse this in the M3
    config file with something like M3CC_MAKE = ["gmake", "BISON=yacc"].

    May need to define NDEBUG when building m3cgc1 to avoid problems with
    "language/modula3/m3compiler/m3cc/gcc/assert.h".