Re: [jdt-debug-dev] Enhancement request for debugging classes without so

[Giuliano Mega <giuliano.mega@xxxxxxxxx>]

Hi Tony,

Well, I'm not a JDT developer nor a Java debug specialist, but I'm
interested in the subject you just brought up.

> Currently when debugging a class with no source code available, eclipse gives very little
> support beyond "step over" or "step return". Also, when source code is available, but the
> debug info has been stripped from the class files (eg, the core JDK runtime classes), then
> you can step over the lines, but you can't examine local variables, and even the method
> param names are generic (not matching the actual source code names).

I had given this some thought while going through the pain of
debugging hand-generated bytecodes. What I came to realize is that
bytecodes might get altered during load (and now they might be altered
later with the new JVMTI), so the real, reliable "source-code" resides
in the debuggee's memory.

As for the symbolic names, I never thought parsing the bytecodes could
help you if the debug information is not there. I'm pretty sure there
are gaps that just can't be filled. Also, someone correct me if I'm
wrong, but if you can follow lines than there has to be at least some
debug information present.

> Alternatively, use a java decompiler to re-generate a version of source code
> for the file (although I don't think any of the decompilers are 100%
> reliable for all possible classes).

Maybe you could get this to work if you have static bytecodes
generated by a Java compiler, but this won't work if you have
generated bytecodes through BCEL, for instance.

> I don't see this anywhere in the current debug platform dev plan, but assume
> it would have to be beyond 3.2 anyway. Is there a list of longer term
> enhancement requests somewhere? If no one else is working on this, I might
> take a look to see how much effort there is in writing an Eclipse debugger
> for "java bytecode language". The "how to write an Eclipse debugger" article
> seems to be a good starting point, but if anyone else has any
> hints/suggestions/reason why this won't work, etc, then please let me know.

Actually, I think the worse issues I could think of (by brainstorming
a bit) are related to how you might build a source-code representation
of the debugee's in-memory bytecodes and manage to keep it consistent.
I also don't know if the StepRequest.STEP_MIN granularity of JDI
corresponds to a bytecode instruction - it states "Location"
granularity, but the meaning of that is not really clear to me.

I can think of more issues, but this e-mail is already long enough. :-)

Anyway, I'd really like to see a runtime Java disassembler in Eclipse,
so if you're willing to take on this endeavour, that's something I
would like to help you with (if you'd like that as well, of course).

Best,

--
Giuliano Mega <giuliano@xxxxxxxxxx>