[Gdb] need help: gdb -k 4.16/7

[Dorr H. Clark]

Hi-

< Please cc: me on any answer as I am not subscribed! Thx! >

I am experimenting with porting an application
from the FreeBSD 2.2.x series to a more modern release,
and as such I have occaision to debug kernel core files
under the old release using the gdb -k option
(saved via savecore).

The problem is the old kernel has been customized
with a different load address (new style 0xC0000000 
vs. old style 0xF0000000).  This change involves 
updating the include file environment.  I have made
those changes coherent between the kernel build tree
and /usr/include, then rebuilt gdb.  The problem
is the resulting gdb -k sessions are not fully 
functional.

I would like to know if anyone knows anything about this
& can help me with some clues.

Specifically, the kernel stack frames are fine,
sources are fine, data/bss access is fine, 
but attempts to access kernel malloc'ed memory fail.
The debugger reports that the address is not accessible.

The implementation of gdb -k in 4.16 uses a file 
kvm-fbsd.c which mimics a real kvm access by reading
from the core file instead.  My understanding is the core
file is a physical image of memory, so this kvm emulation
has some knowledge of the virtual memory system.
I am worried that there are some hidden dependencies
on the original memory layout that were not handled
when the KERNBASE move was reflected in the include files.

After debugging this for some time, in desperation
I attempted to port 4.17 and 4.18 back into the old
FreeBSD environment, hoping to find a bug fix.
What I got instead was a build failure in 4.17:

< gdb 4.17 build log excerpt > 
Graph cycles through config.h

`all' not remade because of errors.
make all-recursive
Making all in doc
rm -f gdb
gcc -g -O2      -o gdb  init.o version.o blockframe.o breakpoint.o findvar.o 
stack.o thread.o  source.o values.o eval.o valops.o valarith.o valprint.o 
printcmd.o  symtab.o symfile.o symmisc.o infcmd.o infrun.o command.o  
expprint.o environ.o gdbtypes.o copying.o i386-tdep.o i387-tdep.o solib.o 
ser-tcp.o ser-unix.o fork-child.o infptrace.o inftarg.o corelow.o core-aout.o 
i386b-nat.o  remote.o dcache.o remote-utils.o tracepoint.o   mem-break.o 
target.o parse.o language.o c-exp.tab.o jv-exp.tab.o f-exp.tab.o m2-exp.tab.o 
buildsym.o  exec.o bcache.o objfiles.o minsyms.o maint.o demangle.o  dbxread.o 
coffread.o elfread.o  dwarfread.o dwarf2read.o mipsread.o stabsread.o 
corefile.o  c-lang.o ch-exp.o ch-lang.o f-lang.o  jv-lang.o jv-valprint.o 
jv-typeprint.o m2-lang.o  scm-exp.o scm-lang.o scm-valprint.o complaints.o 
typeprint.o  c-typeprint.o ch-typeprint.o f-typeprint.o m2-typeprint.o  
c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o  nlmread.o 
serial.o mdebugread.o os9kread.o top.o utils.o annotate.o main.o inflow.o 
gnu-regex.o     ../bfd/libbfd.a ../readline/libreadline.a 
../opcodes/libopcodes.a ../libiberty/libiberty.a  -ltermcap    -lm    
../libiberty/libiberty.a  
gcc: ../libiberty/libiberty.a: No such file or directory
gcc: ../libiberty/libiberty.a: No such file or directory
*** Error code 1

Stop.

< end gdb 4.17 build log excerpt > 

The 4.18 baseline built fine, but gdb -k is no longer supported!

Interestingly, the 4.16 distribution archived at ftp://www.gnu.org
does not exactly match the version in the FreeBSD 2.2.x release,
and doesn't build cleanly either.  The build error from 4.16 
is here:

< gdb 4.16 build log excerpt > 

if [ -n "" ]; then  gcc -O2 -c  -DTRAD_CORE   -I. -I. -I./../include  -g 
trad-core.c -o pic/trad-core.o;  else true; fi
gcc -O2 -c -DTRAD_CORE   -I. -I. -I./../include  -g trad-core.c
trad-core.c: In function `trad_unix_core_file_p':
trad-core.c:108: `NBPG' undeclared (first use this function)
trad-core.c:108: (Each undeclared identifier is reported only once
trad-core.c:108: for each function it appears in.)
*** Error code 1

Stop.

< end gdb 4.16 build log excerpt > 

Anyone who has any clues as to how to overcome any
of these problems, and properly access the old kernel
core files using any of the 4.16, 4.17, or 4.18 baselines,
please email.

Thanks,

-Dorr H. Clark

School of Engineering
Santa Clara University