I have tried building /usr/src (mostly just to see if I can, i.e. how
stable is 1.3, etc.) and have hit a couple of problems. The first is a
compiler core dump:

I rebuilt gcc with the -g flag and tried again. The error was the same.
The -pipe option does not make a difference either (I turned it on as it
seems to run faster when not compiling to disk and it does not seem to
use much memory).

cc -pipe -g -O -I/usr/src/usr.sbin/dhcp/server/..
-I/usr/src/usr.sbin/dhcp/server/../includes
-I/usr/src/usr.sbin/dhcp/server/..
-I/usr/src/usr.sbin/dhcp/server/../includes -Werror  -c dhcp.c
cpp: output pipe has been closed
cc: Internal compiler error: program cc1 got fatal signal 6
*** Error code 1

Stop.

Both times, it left cc1.core behind. With the debug build I got the
following trace out of gdb:

arm-arm-netbsd target configuration is experimental
Report any problems to mark@causality.com

GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for
details.
GDB 4.16 (arm-arm-netbsd), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `cc1'.
Program terminated with signal 6, Abort trap.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libgnumalloc.so.0.0...done.
Reading symbols from /usr/lib/libc.so.12.20...done.
#0  0x101e3114 in kill ()
(gdb) #0  0x101e3114 in kill ()
#1  0x4e4a8 in find_reloads (insn=0x27deec, replace=0, ind_levels=0, 
    live_known=-272646780, reload_reg_p=0x169704) at reload.c:3321
#2  0x39c40 in reload (first=0x273bcc, global=1, dumpfile=0x0) at
reload1.c:993
#3  0x44600 in global_alloc (file=0xbf) at global.c:580
#4  0x1b7a8 in rest_of_compilation (decl=0xbf) at toplev.c:3080
#5  0xf1a68 in finish_function (nested=2612972) at c-decl.c:6790
#6  0x69b8 in L89 () at c-parse.y:311
#7  0x19d8c in compile_file (name=0x287758 "\002") at toplev.c:2222
#8  0x1ce6c in main (argc=9, argv=0xefbfdcf0, envp=0x0) at toplev.c:3908
#9  0x10c8 in start ()
(gdb) 

Any ideas?


My second, and more important problem, is that I can not compile kernels
at present. The problem is that when compiling disassem.c I get a
problem with one of the include files. Unfortunately, I've just realised
that the actual errors are missing from the log file I've got with me!
IIRC it was that SPL_NET was being redefined. In one place it was
defined to expand into a function call, in another it was defined to
'4'.

I am trying to build the RISCPC configuration of the kernel. The exact
compilation line output I've got is:
cc  -O2 -Werror -Wreturn-type -I. -I../../../../arch -I../../../..
-nostdinc -DMACHINE_NONCONTIG -DEXEC_AOUT -DEXEC_SCRIPT -DCPU_SA110
-DCPU_ARM6 -DCPU_ARM7 -DIOMD -DRISCPC -DARMFPE -DFFS -DMFS -DNFS
-DADOSFS -DEXT2FS -DCD9660 -DMSDOSFS -DFDESC -DKERNFS -DNULLFS -DPORTAL
-DPROCFS -DUMAPFS -DUNION -DQUOTA -DFIFO -DNFSSERVER -DGATEWAY -DINET
-DNETATALK -DCOMPAT_43 -DCOMPAT_12 -DSYSVMSG -DSYSVSEM -DSYSVSHM
-DSHMMAXPGS="0x400" -DMEMORY_DISK_HOOKS -DKTRACE -DIRQSTATS -DLKM
-DMOUSE_IOC_ACK -DDIAGNOSTIC -DPOSTMORTEM -DDDB -DMAXUSERS=32 -D_KERNEL
-Darm32 -Wcomment  -c ../../../../arch/arm32/arm32/disassem.c
*** Error code 1

Stop.


The reason I am trying to build the kernel is that I want to try playing
with the SCSI code. Regrettably not to implement DMA transfers (I don't
have the info or experience to start that). My current problem is with
sector sizes. I have a MagOpt removable disk connected to a Powertec
SCSI II. It always reports the bytes per sector as 512 rather than 2048
as it should do for some disks.

AFAICT the problem is in the generic SCSI code rather than the Powertec
driver. But I would be interested to know if anyone has tried such a
drive on a different card. Or even knows of a fix for the problem.


John Harrison
R&D, 3Dlabs