This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi - On Wed, Sep 26, 2007 at 01:42:29AM -0700, Roland McGrath wrote: > [...] The future non-signal mechanism I described there can have a > reporting interface [...] The other part of the problem is > insertion/removal. Naive non-cooperation works if they literally > nest, but not if removal order is not LIFO. I don't have any > implicit-communication solution for that off hand. Yeah, this is roughly why we pointed out some time back that the utrace layer would be well situated to provide a high-level breakpoint-related API. What do you suggest in the interim? Would this hack work: have the second utrace engine refuse to put a breakpoint wherever it suspects another engine may have put one? Or even more pessimistically, can an engine know that another one is already monitoring a given target process, and give up at attach time? (That would defeat some of the promise of utrace, but so it goes.) - FChE
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |