[Bug java/12760] Binary Compatibility: moving a method into a superinterface

["bryce at mckinlay dot net dot nz" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12760



------- Additional Comments From bryce at mckinlay dot net dot nz  2003-10-25 04:16 -------
I wrote that comment, and it is true ;-)

To dispatch an interface call to some object, both an interface reference and the index is required - 
see _Jv_LookupInterfaceMethodIdx. 

Given two interfaces like so:

IA {void a();}
IB extends IA {void b();}

Some class that implements IB has an itable like this:

[IA, a(), IB, b()]

Some code that makes an interface call to b() will be compiled to lookup the interface method 
using (interface IB, offset x) where, for -findirect-dispatch, x is obtained from the otable. 

Now, imagine b() gets moved to IA, and the calling code is not recompiled. The calling code is still 
trying to look up b() in IB, which is perfectly valid by the binary compatibility rules since its in a 
super-interface. However, there is no fixed offset that the class linker can put in the otable for this 
call. -1 can't be used because different classes might inherit the interfaces in different orders, and 
there is multiple inheritance to deal with.

I think the best solution would be to make the "otable" for interfaces have a pair of values - 
interface where the target method is found in addition to offset. Both of these would be passed to 
_Jv_LookupInterfaceMethodIdx. This probably won't effect performance much since the class 
reference will be looked up at runtime anyway under the BC-ABI.