Since ddb is less than wonderful without symbol tables, I've been
looking at ways to teach ddb about the kernel's symbol table.
Unfortunately I can't do it the proper way, via the bootblock, because
NetBSD/sparc doesn't have network bootblocks, and this is for the
diskless work I'm doing.

So I read over ddb/db_aout.c and thought of using the SYMTAB_SPACE
facility.  I built a kernel with "option DDB, SYMTAB_SPACE=70000" and
then planned to build a small patch program to scribble on the
appropriate piece of the resulting kernel to fill in the symbol table.

But then I ran into a problem.  According to hexdump, the resulting
kernel's struct exec header (the first 32 bytes) is

	0000000  008a0107 000abfe0 00023cf0 00012778
	0000010  00007ecc f8004000 00000000 00000000

which unpacks to

	a_midmag = htonl(0x008a0107) = magic=0407[OMAGIC], mid=138[MID_SPARC], flags=0
	a_text = 704480 = 0xabfe0
	a_data = 146672 = 0x23cf0
	a_bss = 75640 = 0x12778
	a_syms = 32460
	a_entry = 0xf8004000
	a_trsize = 0
	a_drsize = 0
	string size = 33563
	N_TXTADDR = 0x2000
	N_DATADDR = 0xadfe0
	N_BSSADDR = 0xd1cd0
	N_TXTOFF = 32
	N_DATOFF = 704512
	N_TRELOFF = 851184
	N_DRELOFF = 851184
	N_SYMOFF = 851184
	N_STROFF = 883644

All the addresses are down in user-land, in spite of the -T f8004000
when the kernel was linked (this taken from SYSTEM_LD in the kernel
build Makefile).  I would expect this to mean that the a.out is a
normal a.out, except that the header does not record that its effective
N_TXTADDR is 0xf8004000 instead of the 0x2000 that is normal for an
OMAGIC executable - and this appears to be so; when I compute file
addresses based on an address offset of 0xf8004000-0x2000, everything
looks normal.  (The ld run that links the kernel also specifies -p,
which does not appear in the ld man page, so it may well be weirded
out.)

What's really baffling me is gdb.  When I sic gdb on the file, it finds
things at their kernel-space addresses!

	Script started on Mon Aug 22 10:51:37 1994
	[Callisto] 1> gdb netbsd
	(no debugging symbols found)...(gdb) 
	(gdb) x/d 0xf80b9128
	0xf80b9128 <db_symtabsize>:	70000
	(gdb) x/d 0xb5128
	0xb5128:	Cannot access memory at address 0xb5128.
	(gdb) x/d 0xb7128
	0xb7128:	Cannot access memory at address 0xb7128.
	(gdb) x/d 0xb9128
	0xb9128:	Cannot access memory at address 0xb9128.
	(gdb) quit
	[Callisto] 2> exit
	Script done on Mon Aug 22 10:59:34 1994

Can some kind soul explain what it is about this file that is telling
gdb how to locate things at their proper addresses?  Provided I'm
willing to hardwire 0xf8004000 as the effective N_TXTADDR, I can
proceed with my patching plan...but (a) I don't like to charge ahead
when there's something I don't understand hovering nearby, and (b) I
shouldn't need to, as the file obviously contains this information
_somewhere_, or gdb wouldn't be able to figure it out.  (The file name
appears to be irrelevant; gdb behaves the same even when I mv the file
to "a.out".)  I could even imagine gdb having 0xf8004000 wired into it
somewhere, but then I can't see what's making it decide to use it.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu

------------------------------------------------------------------------------