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>