Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[9fans] multiprocess truss

2 views
Skip to first unread message

r...@vitanuova.com

unread,
Oct 22, 2001, 4:21:18 PM10/22/01
to
> Have a look at how the truss code in acid handles the hang bit
> and I think you'll find it's not too hard to do what you want. Truss
> deliberately avoids doing what you're asking because otherwise
> programs like rc, mk, etc. are a true pain to truss.

i'd looked at (and tried) leaving the hang bit set; unfortunately, a
new process hangs only on exec, not on fork, which isn't good enough
for truss/trump which both need to be able to set up breakpoints
before the new process has executed a line of code.

i have a feeling it's not possible without a kernel change.

rog.

Bruce Janson

unread,
Oct 22, 2001, 10:56:58 PM10/22/01
to
..

I am unfamiliar with the most recent plan9 tracing support but I
recently bumped into the analogous feature under linux...
There (and perhaps in other ptrace()-based systems?) they seem to
have chosen the wrong default: tracing is not inherited across
fork()s. This means that under linux one must overwrite the
text of a process as it enters a fork() so that the child (and
the parent uninterestingly) either breakpoint trap or loop until
reattached to by the tracer. The tracer then restores the
overwritten text and continues both.

The other default would have been nicer: tracing is inherited
until explicitly cleared. Then tracers would need to know less
about the instruction set of the target architecture (and over-
writing text is, aside from being gross, fragile if interrupted).

But it sounds as though plan9 may have chosen the same default.
If so I would be interested to hear why.

0 new messages