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.
>