Re[2]: [Gc] Android support (static libs only)

Ivan Maidanski ivmai at
Fri Oct 22 23:55:42 PDT 2010

Hi, Manuel!

Tue, 19 Oct 2010 07:28:53 +0200 Manuel.Serrano at

> Hans,
> > 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 
> 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.

As I already wrote (a year ago) - :
__stack_base__ is no longer needed (it was required in GC v7.2alpha4 because NOSYS was defined for Android
(which is, IMHO, wrong, and the generic stack-base-determination algorithm should work, though I haven't tried to run the test)).

FYI (cross-platform): to adjust a thread stack base from the application, call "real" main thru GC_call_with_gc_active.

> > 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.

Yes, it's complicated (and needs refactoring, IMHO) though it's typically easy to add a new port to it (making the file even more larger).

> 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.

How much do these differences influences GC implementation?

I see only difference in "dynamic loading" (as we use Bionics) and the absence of Glib.

> 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 ( with 20 threads on
> Android and I think it's a good test for the GC.

I can't send you a patch but you can try the current CSV snapshot (or you can create the patch by diff 2009-12-08 against v7.2alpha4)

> > 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
> /proc/self
> -- 
> Manuel


More information about the Gc mailing list