On 24/10/2007, Andrew Cornwall <[EMAIL PROTECTED]> 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.
