From owner-freebsd-emulation  Tue Sep  9 20:41:37 1997
Return-Path: <owner-freebsd-emulation>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA01934
          for emulation-outgoing; Tue, 9 Sep 1997 20:41:37 -0700 (PDT)
Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01929
          for <emulation@FreeBSD.ORG>; Tue, 9 Sep 1997 20:41:33 -0700 (PDT)
Received: from right.PCS (right.PCS [148.105.10.31])
	by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id WAA08409;
	Tue, 9 Sep 1997 22:41:28 -0500 (CDT)
Received: (from jlemon@localhost)
	by right.PCS (8.6.13/8.6.4) id WAA06464;
	Tue, 9 Sep 1997 22:40:57 -0500
Message-ID: <19970909224057.32440@right.PCS>
Date: Tue, 9 Sep 1997 22:40:57 -0500
From: Jonathan Lemon <jlemon@americantv.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: hfwirth@ping.at, emulation@FreeBSD.ORG
Subject: Re: Doscmd, debugging with gdb
References: <199709100321.NAA07491@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.61.1
In-Reply-To: <199709100321.NAA07491@godzilla.zeta.org.au>; from Bruce Evans on Sep 09, 1997 at 01:21:30PM +1000
Sender: owner-freebsd-emulation@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 09, 1997 at 01:21:30PM +1000, Bruce Evans wrote:
> >The problem appears to be that gdb is unable to write to any
> >region that is of type OBJT_DEFAULT (default) in the above
> >map, even though it is marked writable.  gdb doesn't have any
> >problems reading from the address, though.
> >
> >A simple test case:
> >
> >	> echo 'main() {}' > test.c
> >	> cc -g test.c
> >	> gdb a.out
> >	(gdb) b main
> >	(gdb) r
> >	> cat /proc/<pid>/map
> >	[.. snip ..]
> >	0x8012000  0x8014000          0         2 rwx COW vnode
> >	0x8014000  0x801c000          0         8 rwx     default
> >	[.. snip ..]
> >	(gdb) set *0x8012000 = 0
> >	(gdb) set *0x8014000 = 0
> >	Error accessing memory address 0x8014000: Bad address.
> 
> `w' apparently means write-protected here :-).  All the r-x COW vnodes
> are writable and all the rwx COW vnodes are non-writable.

No, I don't think that's it; the write to the 'rwx COW vnode' entry
succeeds, while the write to the 'rwx default' entry fails.  

Also, the 'default' region in doscmd was allocated via brk(), so I'd
certainly hope that allocated memory isn't non-writeable.  :-)

I neglected to mention that this was on a -current machine, BTW.
--
Jonathan