cp-tools-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cp-tools-discuss] gnu.bytecode


From: Elliott Hughes
Subject: Re: [Cp-tools-discuss] gnu.bytecode
Date: Sat, 15 Jan 2005 18:02:05 -0800

On Dec 31, 2004, at 00:01, Per Bothner wrote:
It would be nice to be able to dump to a more machine-readable
format - i.e. a classfile assembler.  I know there are such tools,
but I haven't looked much at them.  The format should of course make
it possible to generate invalid classfiles, so one can test classfile
readers nd verifiers.  It should allow *all* the information in a
classfile to be emitted, at least as comments.

[sorry it took me so long to get round to responding.]

what you describe is pretty much what i was trying to write. here's where i got to; it's not finished, but it's good enough that i've actually been using it:

Attachment: GjDump.java
Description: Text document



the output doesn't correspond to any actual assembler, though it's close to being an extended subset of Jasmin. and it's meant to be easier to parse than Jasmin, just in case you need to do it with a script rather than with a JavaCC-generated parser like Jasmin, which seems ugly and over-complicated.

there are a few things that were awkward:

* gnu.bytecode.ClassTypeWriter has several package-access methods, and most of the methods that are public are final. it would have been nice to be able to provide my own ClassTypeWriter subclass.

* it's not always possible to get the exact bytes that made up an attribute in the class file. i can (and do) write bytes corresponding to the attribute's value, but i have no guarantee that they're the same bytes that were read in.

* GjDump.dumpExceptionHandlers could be simpler if there were a better interface to a Code attribute's exception handler table.

* the decoding of modifiers doesn't cover 1.5 class files, and is wrong because it doesn't properly distinguish class modifiers, method modifiers, and field modifiers. (that's why the attached class has its own code to do the decoding.)

The gnu.bytecode/jcf-dump format (they're more-or-less the same)
is strong on emitting all the details in a human-redable format,
but it's not an easily parsable or human-writable format.

it's still a lot better than javap! presumably Sun have something better in-house.

--
http://www.jessies.org/~enh/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]