harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints
Date Wed, 06 Sep 2006 21:32:31 GMT
On Thursday 07 September 2006 00:55 Weldon Washburn wrote:
> Gregory,
>
> The below seems like a reasonable place to start.  Some observations.
> Regular native code debuggers also like to use int 3.  Do you plan to
> somehow chain onto int 3 exception handler so that regular native code
> debugger also works while java debugger is in use?

Debugging the debugger is never an easy task and it won't be easy I think. On 
windows (XP) using VEH handler chains it is already implemented in 
HARMONY-1363 that breakpoits which are not handled by JVMTI should be handled 
by the other handler in chain. On Linux when SIGTRAP is caught and the 
address is not known by JVMTI I think it should crash just like for other 
unknown signal/locations values.

But when the program is ran under debugger, be it VS.NET Studio or gdb, of 
course int3 is caught by the debugger first. When executing the program under 
VS.NET and int3 is encountered stepping over it doesn't result in exception 
which has to th trigger a breakpoint. When executing the program on linux gdb 
allows SIGTRAP to be caught by the program after it catches it first.

I think mixing debugging VM and debugger is very subtle if possible at all. I 
don't think it is possible to make it easier.

> The threading model is 
> somewhat vague.  For example, when thread A hits a breakpoint, the
> remaining threads could be forced to suspend at a GC safepoint by the VM. 
> This would allow the java debugger to swich thread context and read/wriite
> local variables (a very handy feature).  Allowing other Java threads to
> continue executing once a breakpoint has been hit can cause all sorts of
> hard to reason about problems.

The interaction between thread stopped on breakpoint and other if done through 
standard thread manager capabilities. It is up to the user and the JVMTI 
agent to allow or not the other threads to run when some thread is stopped on 
breakpoint. I think that debugging scenarios usually stop all of the threads. 
Profiling will probably not, but they won't access the variables also.

>
> On 9/4/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > Hello
> >
> > Now that DRLVM has some basic implementation of breakpoints in JIT mode
> > as HARMONY-1363 has been created I've decided the same mechanism may be
> > used for
> > implementation of SingleStep JVMTI event [1].
> >
> > I've thought of some draft design for SingleStep implementation using
> > just int3 breakpoints which are already written in HARMONY-1363. It seems
> > to be enough to satisfy JVMTI spec requirements.
> >
> > The way how I think SingleStep could be implemented is setting a new
> > breakpoint on every new bytecode in compiled code. The breakpoint handler
> > would remove SingleStep breakpoints instrumentation from compiled code
> > and set new ones for the next executable location.
> >
> > The tricky parts is to find the next executable location have the
> > following
> > points
> >
> > 1. Turning SingleStep event state on. When this state is turned on all
> > threads
> > should be switched into SingleStep mode. All of them have to have the
> > next after currently executed bytecode marked with SingleStep type
> > breakpoint. 2. New threads when started and SingleStep state is on have
> > to mark the first
> > bytecode marked with SingleStep breakpoint.
> > 3. Any native to Java transition have to mark first executable bytecode
> > of the
> > method with SingleStep type breakpoint.
> > 4. When exception occurs the SingleStep breakpoints have to be removed
> > from
> > the places of the next executable location and set to exception handler
> > starting address instead.
> > 5. Breakpoints handler which would handle SingleStep type breakpoints as
> > well
> > has to distinguish agent set Breakpoints and synthetic SingleStep ones.
> > 6. When SingleStep state is turned off all breakpoints for the next
> > bytecode
> > in all threads have to be deleted.
> >
> > The implementation would require "next bytecode predictor" which would
> > allow
> > the handler of breakpoints to set them on the next bytecode to be
> > executed.
> > For conditional situations it is easiest to have a set of possibly
> > executable
> > locations, or otherwise it would require parsing current Java stack
> > state. The breakpoints predicted for the next bytecode should certainly
> > be kept in
> > TLS for every thread.
> >
> > There is going to be some subtle logic for distinguishing plain
> > breakpoints
> > and synthetic SingleStep ones and turning SingleStep on/off while in
> > SingleStep and/or Breakpoint callback.
> >
> > So in places like #4, #5 and #6 "predicted" breakpoints would have to be
> > added
> > and removed in sets potentially with more than one target address.
> >
> > At the moment I don't see any flaws in this simple design and I'm going
> > to start working on its implementation. Let me know what you think about
> > it. Surely it is a subject for improvement.
> >
> > I am mostly keeping the whole idea in my head and never tried to write it
> > down
> > completely, I may miss describing some nuances since I may think of them
> > as
> > obvious so feel free to ask me.
> >
> > [1]
> > http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#SingleStep
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org

-- 
Gregory Shimansky, Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message