[Top][All Lists]
[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:
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/
- Re: [Cp-tools-discuss] gnu.bytecode,
Elliott Hughes <=
- Re: [Cp-tools-discuss] gnu.bytecode, Per Bothner, 2005/01/16
- Re: [Cp-tools-discuss] gnu.bytecode, Elliott Hughes, 2005/01/16
- Re: [Cp-tools-discuss] gnu.bytecode, C. Brian Jones, 2005/01/16
- Re: [Cp-tools-discuss] gnu.bytecode, Per Bothner, 2005/01/16
- Re: [Cp-tools-discuss] gnu.bytecode, C. Brian Jones, 2005/01/17
- Re: [Cp-tools-discuss] gnu.bytecode, Per Bothner, 2005/01/17
- Re: [Cp-tools-discuss] gnu.bytecode, C. Brian Jones, 2005/01/18
- Re: [Cp-tools-discuss] gnu.bytecode, Per Bothner, 2005/01/18
- Re: [Cp-tools-discuss] gnu.bytecode, C. Brian Jones, 2005/01/19
- Re: [Cp-tools-discuss] gnu.bytecode, Per Bothner, 2005/01/20