From owner-freebsd-hackers Wed Jun 6 10:32:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hpux36.dc.engr.scu.edu (hpux36.dc.engr.scu.edu [129.210.16.36]) by hub.freebsd.org (Postfix) with ESMTP id 9255137B407 for ; Wed, 6 Jun 2001 10:32:43 -0700 (PDT) (envelope-from dclark@applmath.scu.edu) Received: from localhost (dclark@localhost) by hpux36.dc.engr.scu.edu (8.10.2/8.10.2) with ESMTP id f56HWdi03252 for ; Wed, 6 Jun 2001 10:32:39 -0700 (PDT) Date: Wed, 6 Jun 2001 10:32:39 -0700 (PDT) From: "Dorr H. Clark" To: freebsd-hackers@freebsd.org Subject: need help: gdb -k 4.16/7 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi- < Please cc: me on any answer as I am not subscribed! Thx! > < Also, if this is the wrong list please redirect me! 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=20 vs. old style 0xF0000000). This change involves=20 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=20 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,=20 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=20 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 >=20 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 expp= rint.o environ.o gdbtypes.o copying.o i386-tdep.o i387-tdep.o solib.o ser-t= cp.o ser-unix.o fork-child.o infptrace.o inftarg.o corelow.o core-aout.o i3= 86b-nat.o remote.o dcache.o remote-utils.o tracepoint.o mem-break.o targ= et.o parse.o language.o c-exp.tab.o jv-exp.tab.o f-exp.tab.o m2-exp.tab.o b= uildsym.o exec.o bcache.o objfiles.o minsyms.o maint.o demangle.o dbxread= =2Eo 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 j= v-typeprint.o m2-lang.o scm-exp.o scm-lang.o scm-valprint.o complaints.o t= ypeprint.o c-typeprint.o ch-typeprint.o f-typeprint.o m2-typeprint.o c-va= lprint.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 g= nu-regex.o ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopco= des.a ../libiberty/libiberty.a -ltermcap -lm ../libiberty/libiberty.= a =20 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 >=20 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=20 is here: < gdb 4.16 build log excerpt >=20 if [ -n "" ]; then gcc -O2 -c -DTRAD_CORE -I. -I. -I./../include -g tr= ad-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 >=20 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message