This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Doug Kwan (éæå) wrote:

2008-06-30 Doug Kwan <dougkwan@google.com>

        * config/arm/arm.opt (mandroid): New option.
        * config/arm/bpabi.h (ANDROID_LINK_SPEC): New macro.
        (LINK_SPEC): Enable Android specific behaviour when -mandroid is used.
        (CC1_SPEC): Same.
        (CC1PLUS_SPEC): Same.
        (LIB_SPEC): Same.
        (STARTFILE_SPEC): Same.
        (ENDFILE_SPEC): Same.
        (TARGET_BPABI_CPP_BUILTINS): Define __ANDROID__ when -mandroid is
        used.

This version looks reasonable to me. But, I want to allow the ARM backend maintainers a chance to comment. If you don't hear anything in a week, please ping me.


Is it acceptable to add code in arm's backend to recognize
"*-android-*" in DEFAULT_TARGET_MACHINE and turn on -mandroid
automatically?

I don't know. Do we do that in any other backend? In my ideal world, there'd be a "--with-options=" option to configure that would cause the driver to assume those options appeared on every command-line. Then, you could just configure with that. For example:


configure --with-options="-mandroid -meb"

would be a way of saying that:

gcc -c foo.c

should be treated as equivalent to:

gcc -mandroid -meb -c foo.c

Maybe the string passed in could be a specs string which would allow a bit more power, potentially.

Thoughts?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]