This is the mail archive of the
mailing list for the frysk project.
Re: First try of breakpoint support
Mark Wielaard wrote:
Mark, thanks for that. We will have a check on that a while later. One
quick point though, I see that you hardcoded TRAP in breakpoint.java to
0xcc, and assumed that the length of TRAP and original instruction to be
1. I know that your current focus is to make it work on x86 and x86_64.
But the assumption is not true for other architectures.
Great! Nice to know that it is fixed.
And it is in CVS now if you like to check.
And because the opcode of TRAP is ISA dependent. Our point is that it is
better to declare it as a memeber of ISA class, and its subclass
(IsaIA32, IsaEM64T, IsaPPC64...) can inherit and overwrite it in the
time of initialization. In the time of creating a breakpoint,
Breakpoint.java can get the ISA depedent TRAP instruction and its length
at the same time.
Interesting ideas. I had assumed there was already a way to do that. ButReally? in what way can we do that? I am very happy to be educated.
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).
In the aspect of efficiency, page-faulting is obviously weaker than
hardware watchpoint, but much more efficient than single step simulated
ones. To consider what if there is no hardware support or available
hardware resource are used up.
It might be most efficient to try to write the support first on theYes. That is more efficient.
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
- Wu Zhou