This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: First try of breakpoint support
Mark Wielaard wrote:
Great! Nice to know that it is fixed.
And it is in CVS now if you like to check.
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.
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. 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).
Really? in what way can we do that? I am very happy to be educated.
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 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
are debugging.
Yes. That is more efficient.
Regards
- Wu Zhou