FROM: John Polstra
DATE: 02/17/2002 17:15:13
SUBJECT: RE: CVS Repository Mirroring 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".
| 
Mailing Lists
2002 (1905 msgs)