Talk:Java Debug Wire Protocol
From JopWiki
As long as we have no more structured information about JDWP and JOP we will use this page for discussion and move it later to the discussion page.
Contents |
[edit] Symbolic Information
Currently refining my understanding of JDWP needs and separating services among desktop and JOP services. Moving as much as possible to the desktop.
[edit] Debug Thread or Interrupt Handler
I believe a Thread is one simple way to serve the desktop side with the needed services. It should make it possible to work. However, this is not yet closed, will analyse and discuss with you later. At first glance I agree it's much better to debug without a dependency on the scheduler, hence I will try to avoid the Thread solution. But still need to check if it will be feasible or not.
- We should go with an interrupt handler first Martin 06:25, 20 May 2007 (CDT)
[edit] Hardware Changes
We need to add to JOP:
- breakpoint bytecode
- interrupt handler for requests from the PC side via some communication channel
[edit] Stack Changes
About stack change: ok, working on the current structure for now.
About changes on the structure: will continue the design plan as soon as I finish to understand some JDWP implementation details in more depth. You're right, I agree about the breakpoint bytecode and cache flush.
[edit] Unsorted (mail exchange with Paulo)
About real-time debugging, I'll try to make the code inside JOP as simple as possible so as to make WCET analysis easier. If I can do that, it should make possible real-time debugging in Java. Currently I am developing other ideas about WCET, but I'm also playing with this thought.
About the document that describes the build process, it`s fine and works well. I read it and had no problem at first. But after a few weeks I forgot the details. I just expected to type something like "make clean jsim" and have a nice, clean build.
Unfortunately I had just made a lot of changes on my development environment and wanted to check out if everything was working fine. I removed/installed the JDK, udpated paths, updated Eclipse, Ant and another handful of tools. Had to do this because of several changes on JDK 1.5 and 1.6. I moved back to 1.4.2 to avoid missing compatibility issues (Collections in 1.5 changed too much classes).
Then I had bad luck. Make clean. Worked. Make jsim. Break. After a few hours tweaking the environment, installing and removing Java, JOP, moving back and forth between the old config and the new, changing classpaths and checking all the details a few times, I found that the "error" was just a missing "make tools". Drat.
Don't get me wrong... there's nothing wrong with the document. Unfortunately the error message I got from the compiler was confusing and there was no easy way to go around it. After all, everything was working fine. When I changed the JDK and nothing compiled anymore, I assumed it was this (apparently only) change, but I ignored the other subtle change (it was "make clean").
> - Stack change > about the stack structure, please let me know the design details as long as > you plan this change. It should affect my decisions (and code) here.
Will do. However, it will not be done in the next few weeks.
> - About symbolic information > In the past I already had to do that, for a J2ME application. Now I'll use a > similar approach here. There will be one module responsible to manage this > information on the desktop side, split in two parts. One will be responsible > to collect this information during one of the compilation steps (while the > .JOP file is being created). The other will be responsible to provide the > basic services for the JDWP event manager.
Yes, that's a very good approach.
> - Optimizations > By the way, for the first version it may be necessary to debug the code > without proguard transformations. And to be honest, it may not be possible > to debug optimized code at all (unless someone is willing to work without > symbols, which I don't advise). This should not be an issue, right?
No, this is not an issue.
> - Minimizing changes in the structure of JOP > I believe it will not be necessary to change any .VHDL files. I also intend > to avoid creating new bytecodes and also new microcode instructions, if > possible. I want it to be as transparent and independent as possible, this > is the way my design is going.
You will need the breakpoint bytecode for single stepping and a way to flush the cache to perform code manipulation. I will do this support.
> However, it will be necessary to touch the scheduler and I'll need at least > one thread for debugging inside JOP. This may lead to a change on the > initialization code also. I'm planning to use the native methods and maybe > write a few to manipulate the stack, heap and scheduler structures. But will > try to write natives only when (and if) needed, all the rest should be pure > Java.
mmh, do we really need a dedicated debug thread or can we implement it in an interrupt handler. I would also like to debug single threaded programs without starting the scheduler.
> - No real-time temporal behaviour for the debugger > But to check execution times it won't help as much as a real-time task > would. Maybe if debugging is done in batches: let some code run for a while, > stop, observe, etc. > Mentioned it because I am developping some ideas on that (for the future).
Interetsing :-)
> There are also some details on the Makefile files, two or three things I > would like to change later. For instance, you may use "rm -rf" instead of > "rm -r" since the "f" prevents the "rm" command to complain when there are > no files to remove. Just a suggestion.
thanks, changed it and checked it in.
> Another thing is related to the "tools" target, whose products should be a > precondition of the main targets such as "jsim". I had a small problem with > that. This is the kind of thing a Makefile should take care of, instead of > letting the user puzzled against an error message which is unrelated to the > actual issue ("no class found" when the actual problem was a build > dependency).
agree, but than one should catch all dependencies which would make the Makefile very verbose. - and I'm too lazy ;-)
> Usually I also like to add a small "menu" on top of it, to print out > instructions such as the parameters and main targets. It may seem overkill > at first glance, but sometimes this kind of detail makes all the difference > for new users. Specially those used to type "make", see things happening and > adjust/fix it if something goes wrong. Maybe I change it and send you a > sample.
That's also a nice idea. However, 1. I would like to switch to ant and avoid having two build scripts (Makefile and build.xml). 2. There is a document which describes the build process - probably in a too much detail so no one wants to read it ;-)
> By the way, both the makefile and ant file are being maintained?
Up to now yes. But I want to avoid this.
Cheers, Martin
