Subject: Ecoff support broken in 2.0 (was: 2.0 paniced again, more data)
To: None <netbsd-bugs@NetBSD.org>
From: Dieter <netbsd@sopwith.solgatos.com>
List: port-alpha
Date: 01/28/2005 13:06:42
[ netbsd-bugs readers may wish to read the "2.0 paniced again, more data"
  thread in port-alpha if you need more background info ]

Running an ECOFF binary on 2.0 on alpha panics the OS.
Same binary runs fine on 1.6.2 and before.

------- Forwarded Message

> In message <tkrhdl2kpxh.fsf@memory-leak.sm.sony.co.jp>, enami tsugutomo writes:
> > Dieter <netbsd@sopwith.solgatos.com> writes:
> > 
> > > vmcmd_map_zero() at netbsd:vmcmd_map_zero+0x6c
> > 
> > For example, exec_ecoff_prep_zmagic doesn't check if size > 0.
> > 
> > enami.
> 
> Thank you.  Broken ecoff support would explain it.  I have a small ecoff
> program that runs from cron every 5 minutes.  I don't see the ecoff
> program in the ps output, but it's output is piped into cut, which has
> shown up in the ps output when I did ps from the debugger in two different
> panics.

------- End of Forwarded Message

I added a printf to exec_ecoff_prep_zmagic(), and sure enough:

sopwith sync
sopwith echo hi | no_control_m
exec_ecoff.c exec_ecoff_prep_zmagic() eap->tsize=0x4000 eap->dsize=0x2000 eap->bsize=0x0
panic: kernel diagnostic assertion "size > 0" failed: file "uvm/uvm_map.c", line 755
Stopped in pid 1689.1 (bash) at netbsd:cpu_Debugger+0x4:        ret     zero,(ra
)
db> ps
 PID           PPID     PGRP        UID S   FLAGS LWPS          COMMAND    WAIT
>1689          1614     1368        901 2 0x100002    1             bash
 1614             1     1614        901 2  0x4003    1             bash   pause
 1599             1     1599          0 2       0    1             cron nanosle
	[ ... ]
 1                0        1          0 2  0x4000    1             init    wait
 0               -1        0          0 2 0x20200    1          swapper schedul
db> sync
syncing disks... 1 1 1 1 1 1 done
setclock: 53/1/28/20/26/43

dump to dev 8,33 not possible	[ It would be nice if it told me why not? ]
rebooting...

=============================
Also, 1.6.2's size(1) has lost the ability to understand ecoff:

sopwith file /usr/app/bin/no_control_m 
/usr/app/bin/no_control_m: ECOFF NetBSD/alpha binary stripped

sopwith size /usr/app/bin/no_control_m 
size: /usr/app/bin/no_control_m: File format not recognized

sopwith /os/netbsd_1.2/usr/local/bin/size /usr/app/bin/no_control_m 
text    data    bss     dec     hex     filename
11648   3184    3412    18244   4744    /usr/app/bin/no_control_m
sopwith