From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com (Netscape Messaging Server 3.6) with ESMTP id AAA6AE3 for ; Tue, 1 May 2001 11:26:28 -0500 Message-ID: <3AEEEA09.7000301@link.com> Date: Tue, 01 May 2001 12:53:29 -0400 From: "Richard F Weber" MIME-Version: 1.0 Subject: Re: About reading /proc/*/mem References: <3AEEBB22.9030801@link.com> Content-Type: multipart/alternative; boundary="------------030309050001020607090802" Sender: owner-linux-mm@kvack.org Return-Path: To: "Eric W. Biederman" Cc: linux-mm@kvack.org List-ID: --------------030309050001020607090802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric W. Biederman wrote: >"Richard F Weber" writes: > >>Ok, so as a rehash, the ptrace & open(),lseek() on /proc/*/mem should >>both work about the same. After a lot of struggling, I've gotten the >>ptrace to work right & spit out the data I want/need. However there is >>one small problem, SIGSTOP. >> >>ptrace() appears to set up the child process to do a SIGSTOP whenever >>any interrupt is received. Which is kind of a bad thing for what I'm >>looking to do. I guess I'm trying to write a non-intrusive debugger >>that can be used to view static variables stored in the heap of an >>application. >> >>On other OS's, this can be done just by popping open /proc/*/mem, and >>reading the data as needed, allowing the child process to continue >>processing away as if nothing is going on. I'm looking to do the same >>sort of task under Linux. >> >>Unfortunately, ptrace() probobally isn't going to allow me to do that. >>So my next question is does opening /proc/*/mem force the child process >>to stop on every interrupt (just like ptrace?) >> > > >The not stopping the child should be the major difference between >/proc/*/mem and ptrace. > See this is where I start seeming to have problems. I can open /proc/*/mem & lseek, but reads come back as "No such process". However, if I first do a ptrace(PTRACE_ATTACH), then I can read the data, but the process stops. I've kind of dug through the sys_ptrace() code under /usr/src/linux/arch/i386/kernel/ptrace.c, and can see and understand generally what it's doing, but that's getting into serious kernel-land stuff. I wouldn't expect it to be this difficult to just open up another processes /proc/*/mem file to read data from. Is there something obvious I'm missing? It seems to keep pointing back to ptrace & /proc/*/mem are very closely related (ie: the same) including stopping of the child. Thanks. --Rich --------------030309050001020607090802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Eric W. Biederman wrote:

"Richard F Weber" <rfweber@link.com> writes:

Ok, so as a rehash, the ptrace & open(),lseek() on /proc/*/mem should 
both work about the same.  After a lot of struggling, I've gotten the 
ptrace to work right & spit out the data I want/need.  However there is 
one small problem, SIGSTOP.

ptrace() appears to set up the child process to do a SIGSTOP whenever 
any interrupt is received.  Which is kind of a bad thing for what I'm 
looking to do.  I guess I'm trying to write a non-intrusive debugger 
that can be used to view static variables stored in the heap of an 
application.

On other OS's, this can be done just by popping open /proc/*/mem, and 
reading the data as needed, allowing the child process to continue 
processing away as if nothing is going on.  I'm looking to do the same 
sort of task under Linux. 

Unfortunately, ptrace() probobally isn't going to allow me to do that.  
So my next question is does opening /proc/*/mem force the child process 
to stop on every interrupt (just like ptrace?)



The not stopping the child should be the major difference between
/proc/*/mem and ptrace.

See this is where I start seeming to have problems. I can open /proc/*/mem & lseek, but reads come back as "No such process". However, if I first do a ptrace(PTRACE_ATTACH), then I can read the data, but the process stops. I've kind of dug through the sys_ptrace() code under /usr/src/linux/arch/i386/kernel/ptrace.c, and can see and understand generally what it's doing, but that's getting into serious kernel-land stuff. I wouldn't expect it to be this difficult to just open up another processes /proc/*/mem file to read data from.

Is there something obvious I'm missing? It seems to keep pointing back to ptrace & /proc/*/mem are very closely related (ie: the same) including stopping of the child.

Thanks.

--Rich
--------------030309050001020607090802-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux.eu.org/Linux-MM/