linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Richard F Weber" <rfweber@link.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>, linux-mm@kvack.org
Subject: Re: About reading /proc/*/mem
Date: Tue, 01 May 2001 13:03:04 -0400	[thread overview]
Message-ID: <3AEEEC48.80709@link.com> (raw)
In-Reply-To: <Pine.GSO.4.21.0105011231330.9771-100000@weyl.math.psu.edu>

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

The main thing I'm looking to do is examine data that's part of a 
real-time process.  The process's execution can't be interrupted, 
otherwise it makes debugging it inaccurate.  The applications is 
certainly not looking to see every line of code get executed, but rather 
have a real-time monitor of a symbol as it gets modified.  Now 
viewing/selecting the symbol is done through a combination of nm's & a 
console based util (hopefully GTK Based in the future).  Other 
applications include recording this data to disk for later playback & 
analysis.

Now the next logical step would be to create a debug module in the RT 
system itself that dumps out the values we care about.  The problem with 
this is we are looking at a lot of legacy code (done in fortran, C & 
Ada) as well as tons of variables.  By peeking at the memory on the fly 
we can dynamically decide which values are important for this run, 
without having to record all possible data to the disk (which in itself 
would be quite painful since disk accesses would make debugging again 
difficult).

Granted, it's probobally not a very popular application, but it's still 
one which is present in many of the Big Unixes, and so far has me 
stumped as to how to get it working correctly under Linux.

--Rich

Alexander Viro wrote:

>On 1 May 2001, Eric W. Biederman wrote:
>
>>>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.
>>
>
>Could somebody tell me what would one do with data read from memory
>of process that is currently running?
>
>--
>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/
>


[-- Attachment #2: Type: text/html, Size: 2489 bytes --]

  reply	other threads:[~2001-05-01 16:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 13:33 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 [this message]
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=3AEEEC48.80709@link.com \
    --to=rfweber@link.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-mm@kvack.org \
    --cc=viro@math.psu.edu \
    /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