Re: ARM support

[Erik Poupaert <erik dot poupaert at skynet dot be>]

> Standard static linkers won't handle this
> well, because they see that the method is references from some virtual
> method tables.  A smarter linker can do much better, but it needs to
> understand how virtual- and interface- methods are implemented.

If the linker only sees the compiled version of something like:

int myclass_mymethod2(int a, int b)
{
...
}
...
int MYCLASS_MYMETHOD1=1;
int MYCLASS_MYMETHOD2=2;
int MYCLASS_MYMETHOD3=3;
...
int x=(*(a->vtable[MYCLASS_MYMETHOD2]))(a,b);

Here he is obviously dead stuck in the water. There is no way to know if
myclass_mymethod2() is getting used anywhere or not.

In my impression, in order to drag along as few additional classes and methods
along in order to compile and link an entry point, the purging must be done almost at
source level:

main() --> myclass.method1, myclass3.method1 --> myclass2.method1,myclass3.method1,
myclass2.instancevar1 ...

I feel it could be done by resolving the entry point recursively in terms of stuff to
drag along; and only then compile+link the (single?) purged source file(s).

There are actually no changes required in the compiler or in the linker. It rather
requires a source preprocessor. It could be called a "java source purger", or so.

In terms of Gcj, such tool would have to continue resolving symbols at source
level by dragging methods and variables out of the Gcj class libraries, until it
reaches the native methods. A future version of such tool could even go further, and
do the same for the C++/cni sources. The resulting output of such tool can then
happily be presented to the Gcj toolchain; purged already!

And of course Mono doesn't have such preprocessor.