[PATCH][ARM] Support arm-android-eabi

Doug Kwan (關振德) dougkwan@google.com
Sun Jul 13 20:25:00 GMT 2008


Hi

Thanks for iterating this patch with me so many times :)

2008/7/13 Mark Mitchell <mark@codesourcery.com>:

> I thought about suggesting that we move the -mandroid stuff directly into
> bpabi.h, but since that header is also used for GNU/Linux and uClinux, that
> might be odd.  Saying -mandroid to a uClinux compiler -- or a SymbianOS
> compiler! -- doesn't make any sense.  I suppose that's also an argument that
> the option itself ought to go into a separate .opt file.  Would you please
> make that change as well?

No problem.  I agree that -mandroid on SymbianOS does not make sense.
We can use a eabi.opt I suppose.

> So, I do think a new eabi.h header makes sense, though I think it should
> just be "eabi.h"; I'm not sure what the "generic" in "generic-eabi.h" adds.
>  However, I think that we should avoid duplication.  I think the most robust
> may to do that is to have bpabi.h define ARM_BPABI_<something> and
> unknown-elf.h define ARM_ELF_<something>.

I chose generic-eabi.h instead of eabi.h because there are other BPABI
based targets which do not want the new macros. I can certainly drop
the generic bit.

The other suggestions sounds good, I will do the changes.

> In C++ terms, treat the eabi.h as a "derived class" of the other .h files it
> includes, and override "virtual functions" as appropriate.

In other to do that, we must always define these macros in a manner so
that a derived macro can access the parent macro. So this
does not work

base.h

#define FOO ....
...

derived.h

#undef FOO
#define FOO .. /* something that depends on the base macro */

But this does

base.h

#define BASE_FOO ...
#undef FOO
#define FOO BASE_FOO

derived.h

#define DERIVED_FOO ... /* uses BASE_FOO */
#undef FOO
#define FOO DERIVED_FOO

-Doug



More information about the Gcc-patches mailing list