Define USE_EABI_HARDFLOAT when arm_float_abi is 'default'

Define USE_EABI_HARDFLOAT when arm_float_abi is 'default'.

This is in line with pending changes to chrome build using
armhf compiler by default and leave arm_float_abi empty.

Also, allow the arm_float_abi gyp variable to be left as
empty to signal the compiler default (i.e. no argument
passed to the compiler) to be consistent with chrome's
common.gypi.

BUG=308256

[Sam Clegg, 2013-10-28 22:15:18]

If I understand the code correctly this change should
only effect the host binaries as the ARM binaries will
detect the float_abi at compile time and ignore USE_EABI_HARDFLOAT.

[ulan, 2013-10-29 08:53:41]

[+Ross]

Looks good, but I want to make sure that it doesn't break Android.

Once the default is changed in common.gypi, will it pass arm_float_abi="softfp"
for building Android Chrome?

[rmcilroy, 2013-10-29 10:41:27]

+digit who is working on making Chromium use hardfp on Android
+thorne for webview

I believe this should be ok for Chrome (it seems we explicitly set
arm_float_abi=soft in common.gypi).  I'm not sure about the webview where
arm_float_abi is left unset and gets it's flags from the Android build system -
Torne, would this change break the webview?

[Torne, 2013-10-29 11:53:58]

On 2013/10/29 10:41:27, rmcilroy wrote:
> +digit who is working on making Chromium use hardfp on Android
> +thorne for webview
> 
> I believe this should be ok for Chrome (it seems we explicitly set
> arm_float_abi=soft in common.gypi).  I'm not sure about the webview where
> arm_float_abi is left unset and gets it's flags from the Android build system
-
> Torne, would this change break the webview?

Looks like this shouldn't affect the webview where we leave it blank.

[Torne, 2013-10-29 12:17:19]

On 2013/10/29 11:53:58, Torne wrote:
> On 2013/10/29 10:41:27, rmcilroy wrote:
> > +digit who is working on making Chromium use hardfp on Android
> > +thorne for webview
> > 
> > I believe this should be ok for Chrome (it seems we explicitly set
> > arm_float_abi=soft in common.gypi).  I'm not sure about the webview where
> > arm_float_abi is left unset and gets it's flags from the Android build
system
> -
> > Torne, would this change break the webview?
> 
> Looks like this shouldn't affect the webview where we leave it blank.

Oh, no, it sets USE_EABI_HARDFLOAT, so that will presumably break us. Android
doesn't use armhf as far as I know. :/

[ulan, 2013-10-29 12:58:16]

This also will affect standalone builds of V8 for Android. I uploaded a fix
https://chromiumcodereview.appspot.com/46043015/

[Torne, 2013-10-29 12:59:18]

On 2013/10/29 12:58:16, ulan wrote:
> This also will affect standalone builds of V8 for Android. I uploaded a fix
> https://chromiumcodereview.appspot.com/46043015/

For WebView we explicitly do not want to *ever* pass any compiler flags from gyp
that indicate CPU type/features/optimisation, because we want to leave the
platform build's defaults alone. So, that kind of fix won't work for WebView.

[Sam Clegg, 2013-10-29 15:45:17]

On 2013/10/29 12:59:18, Torne wrote:
> On 2013/10/29 12:58:16, ulan wrote:
> > This also will affect standalone builds of V8 for Android. I uploaded a fix
> > https://chromiumcodereview.appspot.com/46043015/
> 
> For WebView we explicitly do not want to *ever* pass any compiler flags from
gyp
> that indicate CPU type/features/optimisation, because we want to leave the
> platform build's defaults alone. So, that kind of fix won't work for WebView.

Thats what I'm trying to achieve with the linux build too.  Just rely
on the default for the compiler (either arm-linux-gnueabi-gcc or
arm-linux-gnueabihf-gcc) and avoid passing this superfluous option to the
compiler (that could contradict the ABI of the compiler's libs).

This seems to work fine in all cases except for V8 which IIUC needs
to build host (x86) binaries that target the target arch (arm).  In
this case it seems that V8 can't detect the float ABI and relies on
gyp to set USE_EABI_HARDFLOAT at gyp time.  I'm assuming that if 
the host binaries have the wrong value for USE_EABI_HARDFLOAT then
things could go badly go wrong, is that right?

Maybe when arm_float_abi is left blank we can detect the value of
USE_EABI_HARDFLOAT by running the compiler with -v?  I'll have
a go at that.

[Torne, 2013-10-29 15:49:58]

On 2013/10/29 15:45:17, Sam Clegg wrote:
> On 2013/10/29 12:59:18, Torne wrote:
> > On 2013/10/29 12:58:16, ulan wrote:
> > > This also will affect standalone builds of V8 for Android. I uploaded a
fix
> > > https://chromiumcodereview.appspot.com/46043015/
> > 
> > For WebView we explicitly do not want to *ever* pass any compiler flags from
> gyp
> > that indicate CPU type/features/optimisation, because we want to leave the
> > platform build's defaults alone. So, that kind of fix won't work for
WebView.
> 
> Thats what I'm trying to achieve with the linux build too.  Just rely
> on the default for the compiler (either arm-linux-gnueabi-gcc or
> arm-linux-gnueabihf-gcc) and avoid passing this superfluous option to the
> compiler (that could contradict the ABI of the compiler's libs).
> 
> This seems to work fine in all cases except for V8 which IIUC needs
> to build host (x86) binaries that target the target arch (arm).  In
> this case it seems that V8 can't detect the float ABI and relies on
> gyp to set USE_EABI_HARDFLOAT at gyp time.  I'm assuming that if 
> the host binaries have the wrong value for USE_EABI_HARDFLOAT then
> things could go badly go wrong, is that right?
> 
> Maybe when arm_float_abi is left blank we can detect the value of
> USE_EABI_HARDFLOAT by running the compiler with -v?  I'll have
> a go at that.

This approach won't work for the webview; there's no way to know what flags will
be passed to the compiler until build time (when the android build system is
invoked). At gyp time there is no way to tell what -mfloat-abi the target will
use. I believe the actual answer in practise is that Android always uses softfp,
but this may not be true forever..

[Sam Clegg, 2013-10-29 16:11:18]

On 2013/10/29 15:49:58, Torne wrote:
> On 2013/10/29 15:45:17, Sam Clegg wrote:
> > On 2013/10/29 12:59:18, Torne wrote:
> > > On 2013/10/29 12:58:16, ulan wrote:
> > > > This also will affect standalone builds of V8 for Android. I uploaded a
> fix
> > > > https://chromiumcodereview.appspot.com/46043015/
> > > 
> > > For WebView we explicitly do not want to *ever* pass any compiler flags
from
> > gyp
> > > that indicate CPU type/features/optimisation, because we want to leave the
> > > platform build's defaults alone. So, that kind of fix won't work for
> WebView.
> > 
> > Thats what I'm trying to achieve with the linux build too.  Just rely
> > on the default for the compiler (either arm-linux-gnueabi-gcc or
> > arm-linux-gnueabihf-gcc) and avoid passing this superfluous option to the
> > compiler (that could contradict the ABI of the compiler's libs).
> > 
> > This seems to work fine in all cases except for V8 which IIUC needs
> > to build host (x86) binaries that target the target arch (arm).  In
> > this case it seems that V8 can't detect the float ABI and relies on
> > gyp to set USE_EABI_HARDFLOAT at gyp time.  I'm assuming that if 
> > the host binaries have the wrong value for USE_EABI_HARDFLOAT then
> > things could go badly go wrong, is that right?
> > 
> > Maybe when arm_float_abi is left blank we can detect the value of
> > USE_EABI_HARDFLOAT by running the compiler with -v?  I'll have
> > a go at that.
> 
> This approach won't work for the webview; there's no way to know what flags
will
> be passed to the compiler until build time (when the android build system is
> invoked). At gyp time there is no way to tell what -mfloat-abi the target will
> use. I believe the actual answer in practise is that Android always uses
softfp,
> but this may not be true forever..

And when you build the webview, I guess you also build the host binary
(mksnapshot)? Perhaps we just need to make the default be softfp for android
and try to autodetect on linux?  Then android will need to deal with the
hardfp issue when it arises.

[Torne, 2013-10-29 16:15:53]

On 2013/10/29 16:11:18, Sam Clegg wrote:
> On 2013/10/29 15:49:58, Torne wrote:
> > On 2013/10/29 15:45:17, Sam Clegg wrote:
> > > On 2013/10/29 12:59:18, Torne wrote:
> > > > On 2013/10/29 12:58:16, ulan wrote:
> > > > > This also will affect standalone builds of V8 for Android. I uploaded
a
> > fix
> > > > > https://chromiumcodereview.appspot.com/46043015/
> > > > 
> > > > For WebView we explicitly do not want to *ever* pass any compiler flags
> from
> > > gyp
> > > > that indicate CPU type/features/optimisation, because we want to leave
the
> > > > platform build's defaults alone. So, that kind of fix won't work for
> > WebView.
> > > 
> > > Thats what I'm trying to achieve with the linux build too.  Just rely
> > > on the default for the compiler (either arm-linux-gnueabi-gcc or
> > > arm-linux-gnueabihf-gcc) and avoid passing this superfluous option to the
> > > compiler (that could contradict the ABI of the compiler's libs).
> > > 
> > > This seems to work fine in all cases except for V8 which IIUC needs
> > > to build host (x86) binaries that target the target arch (arm).  In
> > > this case it seems that V8 can't detect the float ABI and relies on
> > > gyp to set USE_EABI_HARDFLOAT at gyp time.  I'm assuming that if 
> > > the host binaries have the wrong value for USE_EABI_HARDFLOAT then
> > > things could go badly go wrong, is that right?
> > > 
> > > Maybe when arm_float_abi is left blank we can detect the value of
> > > USE_EABI_HARDFLOAT by running the compiler with -v?  I'll have
> > > a go at that.
> > 
> > This approach won't work for the webview; there's no way to know what flags
> will
> > be passed to the compiler until build time (when the android build system is
> > invoked). At gyp time there is no way to tell what -mfloat-abi the target
will
> > use. I believe the actual answer in practise is that Android always uses
> softfp,
> > but this may not be true forever..
> 
> And when you build the webview, I guess you also build the host binary
> (mksnapshot)? Perhaps we just need to make the default be softfp for android
> and try to autodetect on linux?  Then android will need to deal with the
> hardfp issue when it arises.

Probably. digit@ would know better about whether this is ever not softfp on
android..

[Torne, 2015-06-09 11:52:59]

Is this still needed? If so then WebView is no longer a special case as we now
only build it using the standard chromium build process.

[Sam Clegg, 2015-06-09 15:23:59]

On 2015/06/09 11:52:59, Torne wrote:
> Is this still needed? If so then WebView is no longer a special case as we now
> only build it using the standard chromium build process.

As of this change https://codereview.chromium.org/1140503004, the default is now
'hardfp' for linux and 'softfp' for android.   So we have defaults that work and
most people should not need to set arm_float_abi in their GYP_DEFINES.  
Although its a little inelegant to have to set this at all (we should rely on
the compiler), what we have now at least works as expected in most cases, so I'm
happy to drop this change.