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

[Per Bothner]

Elliott Hughes wrote:

> is that the code that reads the LocalVariableTable keeps creating new 
> Scope instances but doesn't link them up.

I just checked in a fix for this, in the Kawa CVS repository,
which is on :pserver:address@hidden:/cvs/kawa
See http://www.gnu.org/software/kawa/Getting-Kawa.html

Disassembly seems to print the LocalVariableTable correctly now.

> > Anyway there is a partial library for disassembly in the
> > newest japitools which I've receive permission to extend and dump into
> > cp-tools.  I will have to add additional lower level support to it but
> > that's okay.  The facets of gnu.bytecode that allow for changing actual
> > bytecode and writing class files back out are useless to me.

If you want to just disassemble, gnu.bytecode will do that.  If you want
to do servious bytecode munging (i.e. instrumentation, optimization)
it's probably not the best tool.  gnu.bytecode is optimized for code
generation: Making it easy to generate efficcient class files,
with low overhead (programmer and run-time).

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.

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.

Note the latest version jcf-dump in the gcc cvs tree no longer by
default dumps the constant table, but you can get it with --verbose.
--
        --Per Bothner
address@hidden   http://per.bothner.com/