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 --]
next prev parent 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