From: "Richard F Weber" <rfweber@link.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-mm@kvack.org
Subject: Re: About reading /proc/*/mem
Date: Tue, 01 May 2001 12:53:29 -0400 [thread overview]
Message-ID: <3AEEEA09.7000301@link.com> (raw)
In-Reply-To: m1oftdozsi.fsf@frodo.biederman.org
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2339 bytes --]
next prev parent reply other threads:[~2001-05-01 16:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-01 13:33 About reading /proc/*/mem Richard F Weber
2001-05-01 15:27 ` Eric W. Biederman
2001-05-01 16:35 ` Alexander Viro
2001-05-01 17:03 ` Richard F Weber
2001-05-01 17:14 ` Alexander Viro
2001-05-02 10:25 ` Stephen C. Tweedie
2001-05-02 11:39 ` Richard F Weber
2001-05-03 17:51 ` Richard F Weber
2001-05-01 16:53 ` Richard F Weber [this message]
2001-05-01 17:09 ` Alexander Viro
2001-05-01 17:29 ` Richard F Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AEEEA09.7000301@link.com \
--to=rfweber@link.com \
--cc=ebiederm@xmission.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.