harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Cornwall" <andrew.pack...@gmail.com>
Subject Re: [classlib] [pack200] Using BCEL for Pack200
Date Thu, 25 Oct 2007 20:25:43 GMT
I think you've solved my problem! I was treating method references as
indices in the class constant pool - and it appears that they should be
indices in the global constant pools. Things worked (almost) fine when I had
just one class, but now I understand why multiple classes were confused.

Thanks!

    Andrew Jr.


On 10/24/07, Alex Blewitt <alex.blewitt@gmail.com> wrote:
>
> On 24/10/2007, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
> > It appears that this is stored with the attributes (I think RSH). Alex,
> if
> > you're reading this - any hints on how AttributeLayouts/Attributes work?
> The
> > spec is not the clearest :-)
>
> You can say that again :-)
>
> As far as I understand, it works like this; given a bytecode band
> which contains (say) invokevirtual (c.f. invokespecial/invokestatic),
> the operand corresponds to an index into bc_methodref. This in turn is
> an index into cp_Method (c.f. cp_IMethod). I suspect they're in order,
> so the first time you see an invokevirtual, you select the first entry
> in bc_methodref; the second reference to invokevirtual is the next one
> and so forth.
>
> Once you've figured out which the methods are being called, they'll
> need to be assembled in the class's bytecode. You'll need to infer a
> CONSTANT_Methodref (10)   which is a pair of class_index and
> name_and_type (and possibly, infer a CONSTANT_NameAndType (12) as
> well). I never got this far, so it's all a guess :-)
>
> NB the methods in the local class are treated differently; the
> invokespecial  (183) is rewritten as invokespecial_this (207) (c.f.
> static/virtual) then instead of pulling the arg from the bc_methodref,
> it comes from bc_methodref_this. It's basically the same idea, but
> instead of using 0..size(bc_method), it applies a filter on the set of
> methods for those that exist in 'this' (which you'll know by now,
> since it's defined in the method_descr ones). Sounds confusing, but
> think of it like this:
>
> methods: a b c d e
> indexes 0 1 2 3 4
>
> invokespecial c
> invokespecial 3
> -> 183 183 ... 2 4 (in bc_methodref)
>
> OTOH if you only have 'c'  and 'e' in the current class, and it's
> calling them in this, then
> invokespecial_this c
> invokespecial_this e
> -> 207 207 .... 0 1 (in bc_methodref_this)
>
> The attributes (and attribute layouts) aren't relevant to the method
> calls here. In fact, forget the idea of 'calls' in the attribute calls
> right now, and just hope to decode things without attributes :-)
> Basically, for a method that has annotations (either parameter
> annotations or others like @Serializable etc., there will be
> attributes in there. If there aren't any, then you won't have to worry
> about the attribute fields. IIRC the attribute layouts are defined in
> a kind of mini-DSL, so an attribute 'call' would be a reference to a
> predefined attribute layout; say, 1->ABCDEFG and 2->GEGEGEG, then an
> attribute call would be '1' which corresponds to an attribute layout
> ABCDEFG. Of course, what that attribute layout means is anyone's guess
> ...
>
> Does any of that help?
>
> Alex.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message