From: ebiederm@xmission.com (Eric W. Biederman)
To: Richard F Weber <rfweber@link.com>
Cc: linux-mm@kvack.org
Subject: Re: About reading /proc/*/mem
Date: 01 May 2001 09:27:09 -0600 [thread overview]
Message-ID: <m1oftdozsi.fsf@frodo.biederman.org> (raw)
In-Reply-To: "Richard F Weber"'s message of "Tue, 01 May 2001 09:33:22 -0400"
"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.
> Second, I would imagine opening /dev/mem (or /proc/kcore) would get me
> into the physical memory of the system itself. How would I know what
> the starting physical memory addresses of a processes data is to start at:
You don't even want to go there. You've got the wrong model in your head.
> 0x08049000-0x804a000 are mapped to the physical address of 0x718368.
Nope 0x718368 is the inode of an on-disk file.
> However Going to this address, and then doing an lseek(SEEK_CUR)out to
> my expected variable offset doesn't get me the result I'm expecting. Is
> the 0x718368 the right location to be looking at, or is there some
> translation that needs to get done (* by page size, translate into
> hex/from hex, etc.) I can't find any documentation indicating what each
> column represents so it's just a stab on my part.
man proc or reading the source works.
> Thanks for the good information so far.
>
> --Rich
>
> --
> 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/
--
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/
next prev parent reply other threads:[~2001-05-01 15:27 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 [this message]
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
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=m1oftdozsi.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=linux-mm@kvack.org \
--cc=rfweber@link.com \
/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.