linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Richard F Weber" <rfweber@link.com>
To: linux-mm@kvack.org
Subject: About reading /proc/*/mem
Date: Tue, 01 May 2001 09:33:22 -0400	[thread overview]
Message-ID: <3AEEBB22.9030801@link.com> (raw)

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?)

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:

What I do see is under /proc/*/maps is the entries:
08048000-08049000 r-xp 00000000 03:01 718368     /devel/mem_probe/child
08049000-0804a000 rw-p 00000000 03:01 718368     /devel/mem_probe/child
40000000-40015000 r-xp 00000000 03:01 310089     /lib/ld-2.2.so
40015000-40016000 rw-p 00014000 03:01 310089     /lib/ld-2.2.so
40016000-40017000 rwxp 00000000 00:00 0
40017000-40018000 rw-p 00000000 00:00 0
40027000-4013f000 r-xp 00000000 03:01 310096     /lib/libc-2.2.so
4013f000-40144000 rw-p 00117000 03:01 310096     /lib/libc-2.2.so
40144000-40148000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0


I would assume that this tells me that memory addresses 
0x08049000-0x804a000 are mapped to the physical address of 0x718368.  
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.

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/

             reply	other threads:[~2001-05-01 13:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 13:33 Richard F Weber [this message]
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
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=3AEEBB22.9030801@link.com \
    --to=rfweber@link.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox