This is the mail archive of the
mailing list for the frysk project.
Re: First try of breakpoint support
- From: Mark Wielaard <mark at klomp dot org>
- To: Wu Zhou <woodzltc at cn dot ibm dot com>
- Cc: frysk at sources dot redhat dot com
- Date: Wed, 16 Aug 2006 16:54:15 +0200
- Subject: Re: First try of breakpoint support
- References: <email@example.com>
On Mon, 2006-08-14 at 22:29 -0400, Wu Zhou wrote:
> Quoting Mark Wielaard <firstname.lastname@example.org>:
> > Yes, I also had some intermittent failures. That first try depended on
> > the timing of the ptrace calls to be right. I have fixed that by
> > integrating the code with the proc and task state machines. That makes
> > sure that the various ptrace calls are made at the right time. This also
> > makes the code much faster.
> Great! Nice to know that it is fixed.
And it is in CVS now if you like to check.
> Yes, non-executable stack is a problem. Is there any way for the
> debugger to change the access attribute of the debuggee pages? AFAIK,
> ptrace can't do that. I am now thinking if utrace can do that. It
> seems to me not that hard. Utrace can register a hook function to do
> that in my opinion.
> If this kind of mechanism is available, it might also help in
> watchpoint implementation. To set a write watchpoint on some address,
> we can set that page to be read-only, a page fault will trigger when a
> write attempt is tried on it, then debugger can fetch that and report
> a write hit; vice versa for read watchpoint. Any ideas?
Interesting ideas. I had assumed there was already a way to do that. But
it seems even gdb uses hardware registers. I don't know if that is
because nobody ever implemented watchpoints by page-faulting, or that
page-faulting is just too inefficient (you could get a lot of false
traps if the page is large).
> Maybe we can
> list first all the possible problem we might encounter. And then
> current available solution, their pros and cons...what support low
> level provide? what we need to ask low-level for? ... based on these,
> we might come up a better solution. Though there are really quite a
> lot of works to be done.
It might be most efficient to try to write the support first on the
frysk side. Using simple CodeObservers that are unconditional. And just
check the conditionals ourselves each time. When we have a feeling for
what kind of conditionals are most commonly used then we can benchmark
and see what can be pushed/injected into the process code pages that we
> Thanks in advance for that. We will be very happy to go thru your code
> and to see if we can provide any feedback. And it is really awful for
> me to hear that you change the state machines three times (I am
> wishing that you don't change that too much so that I don't need to
> spend the same time I need to understand it the first time. :-).
I actually changed very little in the end. The patch that I committed
doesn't add any new states. I am now working on merging the breakpoint
tracing with the syscall tracing and that will also involve merging
states. So we will end up with less states. But some of the states will
have more complex state transition rules.
> >> - Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint
> >> might also share some work flow with breakpoint. Do you have some
> >> consideration in this aspect?
> > There doesn't seem to be a way to set those through something like
> > ptrace.
> On ppc64, there is an extra ptrace command which can do this. I am
> not very sure about the situation in i386 though.
O that is nice. It does indeed seem that you can access the hardware
debug registers through ptrace. But there doesn't seem to be any
documentation (except reading sys/user.h) and it is obviously all
> > I don't have testcases yet. Those should indeed be written asap.
> Yes. A testcase can help understand this situation more easily. I am
> wishing someone can do that. :-)
Writing them as we speak.