Re: [BProc] Access to /proc/<pid>/exe

[<er...@he...>]

On Fri, Dec 12, 2003 at 03:02:40PM -0600, William Hachfeld wrote:
> 
> On Fri, 12 Dec 2003 er...@he... wrote:
> 
> > Bingo.  That's it exactly.  The 'readlink' for that one looks through
> > the process's memory to find a region tagged as 'VM_EXECUTABLE' and
> > tells you what file that one is mapped from.
> > 
> > I haven't done anything to try and make it so I guess it shouldn't. It
> > probably wouldn't be that hard to make it do something reasonable if you
> > really wanted it to work.  It might get a little weird if remote
> > processes exec something that doesn't exist on the front end though.
> 
> Thanks for the response Erik!
> 
> Actually, how badly I wanted this to work may depend on the answer to 
> my next question... How much of the ptrace interface is supported? 

It should be all...  Last I checked, ptrace basically worked fine.  I
usually test it with gdb and strace though.

> I know from your paper at:
> 
>      http://public.lanl.gov/cluster/papers/papers/hendriks-ics02.pdf
> 
> that at least partial support is provided. And some of the text in this
> paper implies that one can, at the very least, peek and poke the remote
> process' address space via the ghost. Is that correct?
> 
> I'm currently trying to get Dyninst (http://www.dyninst.org/) working on
> a bproc cluster. My goal is run a tool implemented using Dyninst on the 
> master node while manipulating processes on the slave nodes. The first 
> problem I encountered was the issue with /proc/<pid>/exe. This was easy 
> enough to work around for the moment. But now I'm running into a Dyninst 
> error message:
> 
> DYNINST ERROR: System error: <>unable to read 256@0x080483C0 from process 
> data space: No such process (pid=4715)
> EXIT DYNINST ERROR: Internal error: unable to find addr of _dl_open
>
> Where pid 4715 is the ghost process for the real process I'm trying to
> manipulate. I realize, of course, that you are not necessarily familiar
> with Dyninst.  I've dug through their source and the error message leads
> me to believe that a call to ptrace(PTRACE_PEEKTEXT, 4715, ...) failed.

Hrm... if PEEKTEXT is generally broken then gdb should be broken too.
Do you know if the address it's using is sensible?

I've seen another debugger break on the front end because
/proc/<pid>/maps was empty.  The ghost has no memory so space so maps
is empty as well.

> Should performing a PTRACE_PEEKTEXT on a remote process work properly? Any 
> caveats involved in doing so? How about the other PTRACE operations? 
> Should they all work? Or just a specific subset?

I think the only caveat is that ptrace is significantly slower than
before.  If you want to see something pretty painful, try using gdb to
ptrace attach to a remote multithreaded C++ program...

- Erik