Comments on Babak Salamat's Research Blog: Low-overhead access to the memory space of a trace...

This is great info to know.

2008-10-29T09:03:00.000-07:00

This is great info to know.

Thanks again for your thorough explanation.
I w...

2008-05-28T12:51:00.000-07:00

Thanks again for your thorough explanation.
I will definitely consider your method and try to implement it.

Regarding the localhost sockets, I think they are not appropriate for this project, because it is very important that no process from other sessions can send any information to the tracer.

Right, I meant that you start with a pipe between ...

2008-05-28T04:55:00.000-07:00

Right, I meant that you start with a pipe between tracer and tracee, and then when the tracee spawns tracee2, there is another pipe created. Initially that also connects tracer and tracee, but tracee then passes its end of the pipe to tracee2. tracer's new thread should be able to access the tracer end of the new pipe fine, since file descriptors are shared among threads, but if tracer2 is a separate process you can pass the fd on that side as well.

tracing the main program:

tracer [pipe] tracee

spawn tracee2:

tracer [pipe] tracee
tracee2

create a new pipe between tracer and tracee:

tracer [pipe] tracee
tracer [pipe2] tracee
tracee2

pass the tracee end of pipe2 to tracee2, and close on tracee:

tracer [pipe] tracee
tracer [pipe2] tracee2

(This is all assuming that you can't just do the setup of the new pipe2 in tracee before forking tracee2, in which case it could be inherited more simply.)

You'll need a unix socket over which to pass the pipe endpoint to traced children, but that's roughly the same as setting up the FIFO, and you only have to use it for the handshake.

There was also a time, at least on Linux, when localhost networking was faster than some FIFO constructs. You might try UDP (with all the checksums turned off) on a lark as well, though the namespace of sockets is a little smaller than that of FIFOs. :)

Thank you very much for your comment.
I guess t...

2008-05-27T22:09:00.000-07:00

Thank you very much for your comment.
I guess the method explained in the link you provided, does not work for my case.
In my project, there is one main tracer that spawns two or more tracees. To make it simple, let's say it spawns just one tracee. We can create pipes between the tracer and the tracee, but if the tracee creates a new child, we also create a new tracer thread and let the new thread trace the child. Now, we need new communication channels between the new tracer and the new tracee and just passing the file descriptors of the existing pipes to them does not work. Those pipes would be used to communicate between the old tracer and tracee and we need new channels.

The method explained in that link explains how to pass open file descriptors to another process.

If you're on a modernish Unix system, I think you ...

2008-05-27T21:17:00.000-07:00

If you're on a modernish Unix system, I think you could probably create a pipe between tracer and tracee, and then have tracee pass the file descriptor for its endpoint to the new child. That would get you back down to the 40-byte threshold, if I'm understanding correctly.

This mailing list post has a good an explanation as you're likely to find of the mechanics.

Comments on Babak Salamat's Research Blog: Low-overhead access to the memory space of a trace...

This is great info to know.

Thanks again for your thorough explanation.I w...

Right, I meant that you start with a pipe between ...

Thank you very much for your comment.I guess t...

If you're on a modernish Unix system, I think you ...

Thanks again for your thorough explanation.
I w...

Thank you very much for your comment.
I guess t...