Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Oct 1996 12:12:42 -0500 (EST)
From:      "John S. Dyson" <toor@dyson.iquest.net>
To:        dyson@FreeBSD.ORG
Cc:        bde@zeta.org.au, jdp@polstra.com, msmith@atrad.adelaide.edu.au, freebsd-current@FreeBSD.ORG
Subject:   Re: kern/1848: breakpoints in shared libraries don't fire
Message-ID:  <199610221712.MAA15306@dyson.iquest.net>
In-Reply-To: <199610212156.QAA01345@dyson.iquest.net> from "John S. Dyson" at Oct 21, 96 04:56:02 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 
> > >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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610221712.MAA15306>