> From: der Mouse  <mouse@cim.mcgill.ca>
> Date: Mon, 22 Aug 1994 11:34:13 -0400
> Message-Id: <199408221534.LAA05684@Thunder.McRCIM.McGill.EDU>
> To: current-users@sun-lamp.cs.berkeley.edu,
>         port-sparc@sun-lamp.cs.berkeley.edu
> Subject: kernel addresses: how?

> 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.

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

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

Kernels are usually linked at an address that is not the same as
the default load address for user programs.  This gets confusing.

> 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.

Gordon W. Ross			  Internet: <gwr@mc.com>
Mercury Computer Systems	Voice mail: 508-256-0052x295
199 Riverneck Road		Front desk: 508-256-1300
Chelmsford, MA 01824-2820	 Facsimile: 508-256-3599

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