Actually what we are looking to do is a lot more simplistic than that what you are suggesting. The RT applications is the Host portion of a flight Sim. So for example, we want to see what the system thinks it's current altitude is at, or what position the throttle is at, etc. So there isn't a lot of dynamic list generation, or pointer manipulation going on. Having dynamic data generation and/or pointers is another nasty hole that gets opened up that nobody here is quite ready to step into.

So the majority of the data is static, as well as small enough to be atomic. Mostly 32-bit floats & ints with occaisional calls to 64-bit floats & ints.

Don't forget too, that since this is running in a real-time environment, that alot of things are expected to be guaranteed. We know a certain process is going to be running at 50 Hz, or 200Hz. So when it's timeslice is complete it really better be done or else we have architecture problems. The child will be getting interrupts & starting, running, & finishing 50 times a second, meanwhile, the debug process may be running at 1 Hzand updating relatively slowly. Assuming this is a uniprocessor, the child process should be totally done running when the debug process goes in to get updates. On an SMP there will probobally be some synchronization problems, but we'll worry about that when we get there.

What I'm trying to do is port an application that was working on Suns, SGI's & Concurrent PowerHawks over to Linux. All three used the /proc to access the memory, and Linux doesn't seem to offer the same kind of support. Which brings me back to my original question of how to tie into the process's memory without interrupting it's execution.

--Rich

Alexander Viro wrote:


On Tue, 1 May 2001, Richard F Weber wrote:

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.


OK, here's something I really don't understand. Suppose that I tell your
debugger to tell me when in the executed program foo becomes greater than
bar[0] + 14. Or when cyclic list foo becomes longer than 1 element
(i.e. foo.next != foo.prev).

How do you do that if program is running? If you don't guarantee that
it doesn't run during the access to its memory (moreover, between sever
such accesses) - the data you get is worthless.