[Bug uprobes/10836] uprobes-provided pt_regs* are unreliable

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From fche at redhat dot com  2009-10-27 12:27 -------
(In reply to comment #1)
> > Several registers appearing in a utrace-oriented pt_regs do not accurately
> > represent the state of the user-space task. 
> 
> Is this concern about instruction pointer pointing past the breakpoint?

No, not only.

> or do we have additional concerns? If yes do we have specific registers in mind?

It depends.  Sometimes esp, sometimes ebp, and I think I've seen other
registers with inconsistent values too.  Compare a systemtap print_regs
with a gdb breakpoint "info regs" at the same spot.

                                     
> uprobes passes the pt_regs it gets from utrace's report_signal callback as is to
> the handler.

Yes.  Unfortunately, these registers do not completely & correctly match the
state of the user-space thread.


> This bug refers to two other bugs which point to problems in user space markers.
>  So is this problem only seen on user space markers? or can we see this problem
> on plain uprobes probe points too.

In this context, user-space markers are a special case of uprobes.  Statement
uprobes (bypassing prologue heuristics) at the function entry point also
display this problem.


> Is there any reason why this synthesis should be done at the uprobes end and not
> at the client end?

I believe I summarized some pros & cons already.  Hiding the regset
stuff from uprobes clients would be the main benefit.  Perhaps the
run-time costs of doing this could be controlled by a struct-uprobes
flag that tells uprobes whether the client is interested in raw
pt_regs, nothing, or regset-filled pt_regs.

> Do you see all uprobe clients facing this problem?

Yes.

> If its a problem faced by all uprobe clients, then is it worth checking if
> utrace should send the synthesized pt_regs as a parameter to report_signal.

Roland?


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10836

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.