[Gc] Android support (static libs only)

Boehm, Hans hans.boehm at hp.com
Mon Oct 18 13:08:32 PDT 2010


Manuel -

Thanks.  I did miss that use of __stack_base__ and the previous discussion.

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

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 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
either HEURISTIC1 (and probably STACK_GRAN) or HEURISTIC2?  What does a typical stack base
look like?  I assume /proc/self/maps doesn't exist?

Hans



> -----Original Message-----
> From: Manuel.Serrano at inria.fr [mailto:Manuel.Serrano at inria.fr]
> Sent: Monday, October 18, 2010 12:01 PM
> To: Boehm, Hans
> Cc: gc at linux.hpl.hp.com
> Subject: RE: [Gc] Android support (static libs only)
> 
> Hi Hans,
> 
> > Thanks.  Some of this already seems to be in CVS.  But I have some
> concerns:
> Yes, we have already sent you some but not all of them.
> 
> > Where is BGL_ANDROID defined?  We seem to also be testing for
> PLATFROM_ANDROID, but not consistently.
> BGL_ANDROID is defined nowhere. That's what I meant when I said that
> you have to compile the GC with -DBGL_ANDROID. I don't think that it is
> possible to autoconfigure this variable automatically because for
> compiling for Android you simply use a cross compiling gcc. You do not
> compile understand any special environment that would give you a chance
> to find out by yourself that your are generating code for Android.
> 
> Regarding PLATFROM_ANDROID and BGL_ANDROID, I wanted to isolate the new
> patch from what we have already sent. For the inclusion in your source
> code two macros do not make much sense. Renaming BGL_ANDROID with
> PLATFORM_ANDROID is probably the best solution.  The only advantage of
> this BGL_ANDROID is that it's easier for your, I guess, to see what are
> the new modifications.
> 
> > __stack_base__ seems to be set, but not used?
> It is (or I sent you something wrong). I think (my memory may be
> erroneous) that it is used in gcconfig.h. The definition of STACKBOTTOM
> falls back to NOSYS which defines STACKBOTTOM as:
> 
> #     define STACKBOTTOM ((ptr_t) (__stack_base__))
> 
> > Some of the patch seems to consist of Bigloo profiling changes, which
> are orthognonal, and look like they may be redundant with other
> mechanisms already in the GC.
> Yes. You are correct. That's also what I said. This patch is the
> genuine file I'm using for Bigloo. It needs some cleanup if your
> intention is to add it to the main distribution tree.
> 
> > Makefile.in is a derived file.  Makefile.am should be edited if
> changes are needed.
> Yes you are right. However it's sometimes it's such a pain to use
> autoconf/automake/... than patching the Makefile.in is simpler than
> struggling with the installation of some obscure m4 macros file that
> turns out to be incompatible with your XXX.am files. Anyhow, the only
> parts of the patch that are of some interest for you are those that
> deal with BGL_ANDROID.  All the other ones are irrelevant. I just have
> not had the time to make the cleaning before sending the patch to you
> and I thought it sill might be interesting for you and the users of the
> collector.
> 
> Sincerely,
> 
> --
> Manuel



More information about the Gc mailing list