[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