incremental arch work

[Ananth N Mavinakayanahalli]

On Tue, Jan 22, 2008 at 06:30:41PM -0800, Roland McGrath wrote:

> The only things akin to specific plans I have in mind are those I've
> discussed before and that are already on the TODO list.  In particular,
> the "engine interaction issues" area comes to mind.  (See
> https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and
> https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html
> for detailed background.)  This is something we are already pretty sure we
> need to revamp, so hashing that out before preparing something for
> submission seems like a good idea.

For atleast the ordering of engine callbacks, we could use notifiers
something akin to what we do with kprobes in the kernel. (We had touched
upon this topic earlier, see
http://sources.redhat.com/ml/systemtap/2006-q3/msg00235.html). But, as
you've characterized in the "engine interaction, callback order" thread,
this is probably not as straightforward in the utrace case, after all.

> Working on a well-heeled breakpoint
> facility that manages in the presence of other engines both to work right
> and not to confuse the other engines would is a fine way to pin down the
> concrete details of those interface changes.

One way to simplify matters, atleast in the breakpoint case, maybe, is
to just refuse to install breakpoints at virtual addresses whose
underlying opcode is that of a breakpoint. In the uprobes code currently,
there are checks that refuse uprobe insertion if that is indeed the case.
Maybe its a worthwhile feature to incorporate in the factored out
breakpoint facility.

Ananth