Subject: kernel addresses: how?
To: None <firstname.lastname@example.org,>
From: der Mouse <email@example.com>
Date: 08/22/1994 11:34:13
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
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.
[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.