Some time ago I wrote under this subject about a crash of sysinst on
sparc, on the netbsd-1-6 branch, that I was trying to debug.

Well I've now got a 100% reproducible crash of sysinst on alpha (also on
the netbsd-1-6 branch of course) that seems to be happening in exactly
the same place as it does on the sparc, at least given the hints I've
got from GDB so far.  I simply select the "Utilities" menu, then the
"Logging functions" menu, then try to exit the latter and SIGSEGV
causing the crash occurs almost immediately.  This is a most unfortunate
place for it to crash because I'm trying to debug another problem which
I've added some more logging output to help with....  :-(

I just wanted to post again about my methodology of building a
GDB-friendly version of "ramdiskbin" before I send a PR because I'm
having some trouble getting GDB to work consistently on the alpha.

First note I already have things arranged such that CFLAGS already
includes "-g" (I'm always building everything with '-g' now!  ;-)

Then what I'm doing is going into $MAKEOBJDIRPREFIX to the location
where the crunchgen'ed binary is ultimately built (which is
.../distrib/alpha/instkernel/ramdisk for the alpha) and then running:

	$TOOLSDIR/bin/nbmake-alpha -f ramdiskbin.mk clean
	$TOOLSDIR/bin/nbmake-alpha -f ramdiskbin.mk STRIP=: all

However on the alpha I have some troubles with undefined symbols in
dd.cro and pax.cro.  I have to re-compile dd's objects with
'DBG=-DNO_CONV' and pax's objects with 'DBG=-DSMALL' to work around
this.  Unfortunately the result has a radically different stack
backtrace, presumably because my re-compiled binary is too different
from the one that generated the core.  I don't remember having this
problem on the sparc, and as you can see in my original post[1] there is
a full stack backtrace.

Initial stack backtrace on alpha from the original binary with no
debugging symbols:

	#0  0x1201055e0 in process_menu ()
	#1  0x1201422fc in makech (wy=538678904)
	    at /proven/work/woods/m-NetBSD-1.6/lib/libcurses/refresh.c:484
	warning: Hit heuristic-fence-post without finding
	warning: enclosing function for address 0x120386000
	This warning occurs if you are debugging a function without any symbols
	(for example, in a stripped executable).  In that case, you may wish to
	increase the size of the search with the `set heuristic-fence-post' command.
	
	Otherwise, you told GDB there was a function where there isn't one, or
	(more likely) you have encountered a bug in GDB.

Stack backtrace from the re-compiled alpha binary with debugging symbols:

	#0  0x1201055e0 in opt_act_10_2 ()
	#1  0x1201422fc in winsdelln (win=0x2000000, lines=28)
	    at /proven/work/woods/m-NetBSD-1.6/lib/libcurses/insdelln.c:100
	Cannot access memory at address 0xfffffffffffffffd

[1] my original post about the sysinst bug on sparc is here:

	http://mail-index.netbsd.org/current-users/2003/06/08/0007.html

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>