Re: gnu.bytecode

[Brian Jones <cbj at gnu dot org>]

Per Bothner <per@bothner.com> writes:

> Brian Jones <cbj@gnu.org> writes:
> 
> > Could someone explain to me where to find a LocalVarsAttr when
> > starting with a ClassType?  I would assume it might be part of a
> > Method's attributes,
> 
> Nope.  Check the JVM spec.  It is part of a CodeAttr's attributes,
> where the CodeAttr is the "Code" attribute of a method.

Thanks, I thought I had tried that correctly before but this time it
works.  I had probably forgotten to compile with -g.

> > Just an observation, it seems like it may be difficult to include
> > disassembly information without largely duplicating the code within
> > disassemble() of CodeAttr.
> 
> Not sure what you mean by "disassembly information".  Perhaps you can
> explain what you want to do and why it seems difficult with the current API.

This is output from Sun's javap -c

Method void main(java.lang.String[])
   0 aload_0
   1 invokestatic #2 <Method gnu.classpath.javap.Javap parseArguments(java.lang.String[])>
   4 astore_1
   5 aload_1
   6 invokevirtual #3 <Method int exec()>
   9 istore_2
  10 iload_2
  11 invokestatic #4 <Method void exit(int)>
  14 return

This is partial output from gnu.bytecode.dump for the same method

  0: aload_0
  1: invokestatic #2=<Method gnu.classpath.javap.Main.parseArguments (java.lang.String[])gnu.classpath.javap.Javap>
  4: astore_1
  5: aload_1
  6: invokevirtual #3=<Method gnu.classpath.javap.Javap.exec ()int>
  9: istore_2
 10: iload_2
 11: invokestatic #4=<Method java.lang.System.exit (int)void>
 14: return

The output varies slightly and I'd like to correct this within my
program.  It appears both the code byte array and code length are
indeed available from the API here.  The matter of interpreting these
is a very long function called disAssemble.

Was there any problem with adding those two methods in my patch to gnu.bytecode?

Thanks,
Brian
-- 
Brian Jones <cbj@gnu.org>