From owner-freebsd-hackers Fri Feb 27 18:03:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA21984 for freebsd-hackers-outgoing; Fri, 27 Feb 1998 18:03:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA21939 for ; Fri, 27 Feb 1998 18:02:57 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id MAA04866; Sat, 28 Feb 1998 12:32:54 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id MAA15832; Sat, 28 Feb 1998 12:32:53 +1030 (CST) (envelope-from grog) Message-ID: <19980228123253.24049@freebie.lemis.com> Date: Sat, 28 Feb 1998 12:32:53 +1030 From: Greg Lehey To: Mike Smith Cc: FreeBSD Hackers Subject: Re: Kernel debugging: what's going on here? References: <19980228122110.36590@freebie.lemis.com> <199802280156.RAA29982@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199802280156.RAA29982@dingo.cdrom.com>; from Mike Smith on Fri, Feb 27, 1998 at 05:56:46PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 February 1998 at 17:56:46 -0800, Mike Smith wrote: >> On Fri, 27 February 1998 at 17:45:39 -0800, Mike Smith wrote: >>>> Can anybody explain this to me? I'm writing a disk block, and am >>>> currently at bwrite: >>>> >>>> (kgdb) bt >>>> #0 bwrite (bp=0xf051ec00) at ../../kern/vfs_bio.c:364 >>>> #1 0xf0138d6a in vop_stdbwrite (ap=0xf2a76c74) at ../../kern/vfs_default.c:283 >>>> #2 0xf0138bb1 in vop_defaultop (ap=0xf2a76c74) at ../../kern/vfs_default.c:130 >>>> #3 0xf0146639 in spec_vnoperate (ap=0xf2a76c74) at ../../miscfs/specfs/spec_vnops.c:127 >>>> #4 0xf01c5679 in ufs_vnoperatespec (ap=0xf2a76c74) at ../../ufs/ufs/ufs_vnops.c:2242 >>>> #5 0xf2aab097 in VOP_BWRITE (bp=0xf051ec00) at vnode_if.h:1117 >>>> #6 0xf2aa95c4 in vinumstart (vol=0xf0563000, bp=0xf10f1bb0) at request.c:228 >>>> #7 0xf2aa9189 in vinumstrategy (bp=0xf10f1bb0) at request.c:71 >>>> #8 0xf2aa7b63 in vinum_writedisklabel (vol=0xf0563000, lp=0xf0563110) at io.c:830 >>>> >>>> I've handed a buffer header up from frame 6 (not the bp in the >>>> parameter list). When it gets to bwrite, it has a different content. >>>> gdb tells me different contents depending on the frame it's in: >>> >>> My guess would be that the bp has been translated to reflect the block >>> device that it will be operating on at bwrite level rather than the >>> logical device that you were operating on when you called VOP_BWRITE. >>> >>> This would involve a change in vnode, as well as (maybe) offset etc. >> >> Look at the addresses. They're the same: > > Yes, I noticed. But rewriting the bp on the fly is not uncommon; quite > a few device drivers do it, it wouldn't surprise me if it wasn't done > elsewhere rather than cloning the original. Sure, all sorts of things modify the buffer header. But you're still missing the point: the processor is stopped here, it's in the debugger. No instructions were executed between the two views. You might just as well take a look at a dump. Since when does the content of memory differ depending on where you look at it from? Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message