[Gc] Android support (static libs only)

Manuel.Serrano at inria.fr Manuel.Serrano at inria.fr
Mon Oct 18 22:28:53 PDT 2010


> My immediate reaction is that treating Android as NOSYS seems highly
> counterintuitive, and is likely to hurt us in the long run.  It's also
Yes. I agree with that. It took me about half a day to understand why
all the debug facilities where not activated on Android. I ended up 
understanding that this was due to the NOSYS configuration, so yes,
NOSYS is not intuitive :-)

> inconsistent with current code in gcconfig.h that defines LINUX for
> PLATFORM_ANDROID.  Is there really no combination of macros that
> identifies the target?  At least one web page suggests that __ANDROID__
> might work?
No, it does not. The wrapper I use (based on 
https://github.com/tmurakam/droid-wrapper) defines ANDROID but that's only
the wrapper. Someone using something else won't have this macro defined. 

> Setting the stack base in GC_init is also not really correct, since
> there may be stack frames that will eventually hold pointers below
> GC_init.  Is the stack base not well aligned?  Wouldn't it work better
Yes. I know that. In a previous version we were setting __stack_base__
in our own C main function before calling GC_init. That is at the very
beginning of the application. I understand this is safer but it also
requires another initialization to take place even before GC_init is
called, which, IMHO, is not that great. 

On some platform the GC emits a warning such as: "GC_init must be
explicitly called before...". Then, I thought it was correct, although
dangerous, to set __stack_base__ in GC_init.

> to treat Android as a particular Linux variant and have the gcconfig.h
> section that handles ARM32/LINUX (around line 1853 in cvs) not define
> LINUX_STACKBOTTOM or DYNAMIC_LOADING for Android, but instead define
I don't know. I'm a little bit confused by the configuration
architecture of gcconfig.h.  I don't have a global view of how it works
and where things should be changed. On the other hand, I'm not sure we
will go very far with considering Android as a Linux box. Yes, the
kernel is a Linux kernel but everything else is different. The thread
library is different, the includes are different, etc.  However, if you
want to sent me a patch (against 7.2alpha4), I will be glad to test it
for you. I'm now running Hop (https://hop.inria.fr) with 20 threads on
Android and I think it's a good test for the GC.

> either HEURISTIC1 (and probably STACK_GRAN) or HEURISTIC2?  What does a
> typical stack base look like?  I assume /proc/self/maps doesn't exist?
Good guess:

# ls -a /proc/self

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20101019/d4968b13/attachment.pgp

More information about the Gc mailing list