From owner-freebsd-current  Tue Oct 22 10:13:12 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA16064
          for current-outgoing; Tue, 22 Oct 1996 10:13:12 -0700 (PDT)
Received: from dyson.iquest.net ([198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA16056;
          Tue, 22 Oct 1996 10:13:05 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id MAA15306; Tue, 22 Oct 1996 12:12:43 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199610221712.MAA15306@dyson.iquest.net>
Subject: Re: kern/1848: breakpoints in shared libraries don't fire
To: dyson@FreeBSD.ORG
Date: Tue, 22 Oct 1996 12:12:42 -0500 (EST)
Cc: bde@zeta.org.au, jdp@polstra.com, msmith@atrad.adelaide.edu.au,
        freebsd-current@FreeBSD.ORG
In-Reply-To: <199610212156.QAA01345@dyson.iquest.net> from "John S. Dyson" at Oct 21, 96 04:56:02 pm
Reply-To: dyson@FreeBSD.ORG
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > 
> > >The text segment starts out read-only.  GDB does (or at least did)
> > >change the protections to read/write as needed when it has to insert a
> > >breakpoint.  As John-Mark Gurney pointed out in a different posting,
> > >this all used to work just fine.  If it's broken now in -current, then
> > >it's probably a problem with gdb.
> > >
> > >I just checked it on a current from just a few days ago, and it works
> > >fine for me.  I was able to set a breakpoint on gethostbyname() in libc,
> > 
> > It's broken somewhere in vm now.  procfs_domem() returns 0 without
> > writing anything, as if for EOF.  (procfs_rwmem() gets to the
> > (writing && object->backing_object) case.  Then m == 0 and vm_fault()
> > returns 0, but the faulted-in page is not used.)
> > 
> I'll fix!!!
> 
Status report:  This is a strange one.  I can make it go-away, and there
is both a bug somehow in vm_map/vm_mmap and also in procfs_mem...  The
procfs_mem problem is easy.  The vm_mmap thing is gone in my code with
a minor change (and it should'nt be.)  There is something else lurking.  So,
I am working the problem actively, and it is subtile.

John