>> 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.
> The program to do this already exists in: /src/usr.sbin/dbsym/

Oh, good.  Thanks for the pointer.

> I suggest you first try out dbtest.c on the sparc, then try dbsym.c
> on a kernel built with SYMTAB_SPACE=something.

> I think these will work OK on the sparc.

As OK as they'll work anywhere.  There's a bug in dbtest.c as
distributed; about ten lines from the end it has
"uatdbxxxxcxxxxxxx"[st>1] which should be "uatdbxxxxcxxxxxxx"[st>>1]
(otherwise most to all symbols get printed as type A by dbtest).  In
order to make it easy to compare dbtest's output with nm -ap output, I
also changed %08X to %08x two lines farther down.

dbtest also complains "symbol table missing null terminator".  I'm not
sure whether this is a meaningful complaint or not, but I didn't get
your note until I'd already gotten my symbol-patching script working,
so I just went ahead and used mine.

Anyway, I now have ddb with very nice symbols.  But now the diskless
kernel doesn't hang any longer!  Frustrating in a way, but I'm not
about to look a gift horse in the mouth....

>> What's really baffling me is gdb.  When I sic gdb on the file, it
>> finds things at their kernel-space addresses!
> Yes, gdb is confused by executables linked with -T non_standard_addr.

What was confusing me is that gdb _wasn't_ confused; it was using the
correct addresses.  pk sent me a note explaining what was up with gdb,
and now that I understand it, it doesn't bother me....

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu

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