Introduce allocator shim for Android

Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path.
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a
bad state in these days.

BUG=550886, 598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*

Committed: https://crrev.com/40b65c66b855b58cb2fda9228b7626f2904581a5
Cr-Commit-Position: refs/heads/master@{#386382}

[Primiano Tucci (use gerrit), 2016-04-06 09:47:56]

Description was changed from

==========
WIP android experiments

BUG=
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depends on //base:allocator (hence //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_XXX symbols are provided by the linker and resolve
   against what would have been the original "malloc" symbol.

In summary, once the linking is done, this entire trickery is invisible
to the dynamic loader, which still sees undefined symbol references
to malloc / calloc / free symbols, that will be resolved against libc.so
(or whatever other weird choice the Android BSP made) as usual.

All this trickery is a noop when use_experimental_allocator_shim=true.

Stability considerations
------------------------
TODO

Performance considerations
------------------------
TODO

BUG=550886
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-06 17:04:38]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depends on //base:allocator (hence //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_XXX symbols are provided by the linker and resolve
   against what would have been the original "malloc" symbol.

In summary, once the linking is done, this entire trickery is invisible
to the dynamic loader, which still sees undefined symbol references
to malloc / calloc / free symbols, that will be resolved against libc.so
(or whatever other weird choice the Android BSP made) as usual.

All this trickery is a noop when use_experimental_allocator_shim=true.

Stability considerations
------------------------
TODO

Performance considerations
------------------------
TODO

BUG=550886
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=true.

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

BUG=550886
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-06 17:12:35]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=true.

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

BUG=550886
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=true.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-06 17:13:11]

primiano@chromium.org changed reviewers:
+ thakis@chromium.org

[Primiano Tucci (use gerrit), 2016-04-06 17:13:11]

Hi, I'm back!
Nico, I still have to look to perf numbers and fix build on cast_shell (should
be a matter of figuring out the right build conditions), but... can I get a
preliminary feedback on  this?

[Primiano Tucci (use gerrit), 2016-04-06 17:16:23]

On 2016/04/06 17:13:11, Primiano Tucci wrote:
> Hi, I'm back!
> Nico, I still have to look to perf numbers and fix build on cast_shell (should
> be a matter of figuring out the right build conditions), but... can I get a
> preliminary feedback on  this?

Ok I also screwed up Android host builds (device forwarder & co), but that's the
least problem.

[Primiano Tucci (use gerrit), 2016-04-07 16:10:51]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=true.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-08 09:53:54]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, static, official build): 24k
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-08 10:09:41]

Patchset #5 (id:80001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 10:09:46]

Patchset #4 (id:60001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 10:09:52]

Patchset #3 (id:40001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 10:09:56]

Patchset #2 (id:20001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 11:18:08]

Patchset #3 (id:120001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 11:18:16]

Patchset #2 (id:100001) has been deleted

[Primiano Tucci (use gerrit), 2016-04-08 18:38:40]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android.
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, static, official build): 24k
TODO check results from trybots and bin size diff.

[1]
https://docs.google.com/document/d/1xMbBA0w5UunhTzZkdUfFIS63nRNjU6PP3wd2vf1_C...

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two extra mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's noise.

All the other perf trybots failed. The perf waterfall seems to be in a bad
state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-08 18:38:58]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two extra mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's noise.

All the other perf trybots failed. The perf waterfall seems to be in a bad
state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two extra mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's noise.

All the other perf trybots failed. The perf waterfall seems to be in a bad
state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-08 18:41:18]

Ok I fixed build issues and did perf investigations.
This is ready from my side. 
Nico, can you take a look to this?

[Nico, 2016-04-08 20:23:07]

lgtm as far as i can tell. consider landing the part that toggles the flag
separately, then your revert/relands might be smaller.

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
File base/allocator/allocator.gyp (right):

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator.gyp:419: # On Android all references to malloc & fridns
symbols are
nit: typo fridns

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
File base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc
(right):

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc:51:
&RealMalloc,   /* alloc_function */
can't these entries just be __real_malloc and friends? or does that confuse the
loader?

Ah, no, because of the alias() stuff in the next file

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc:56:
nullptr,         /* next */
nit: align

[Primiano Tucci (use gerrit), 2016-04-11 13:46:20]

Description was changed from

==========
Introduce and enable allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Build/Perf sheriffs heads up
----------------------------
If you see any build error or crash related with __wrap_malloc,
__wrap_free, __real_malloc, __real_free, etc this CL is to blame.


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two extra mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's noise.

All the other perf trybots failed. The perf waterfall seems to be in a bad
state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a 
bad state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[Primiano Tucci (use gerrit), 2016-04-11 13:49:14]

Thanks for the review Nico.
Splitting out the enabling in crrev.com/1875043003
Also I realized that in this code I was referring to README.md but did not add
the changes to the file. Fixed.

+kraynov,dskiba and ssid fiy
(Note this change will go live only after crrev.com/1875043003)

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
File base/allocator/allocator.gyp (right):

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator.gyp:419: # On Android all references to malloc & fridns
symbols are
On 2016/04/08 20:23:07, Nico (hiding until Fri) wrote:
> nit: typo fridns

Done.

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
File base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc
(right):

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc:51:
&RealMalloc,   /* alloc_function */
On 2016/04/08 20:23:07, Nico (hiding until Fri) wrote:
> can't these entries just be __real_malloc and friends? or does that confuse
the
> loader?
> 
> Ah, no, because of the alias() stuff in the next file

The actual reason is that RealMalloc & co method signatures take an
AllocatorDispatch* argument as first args. Instead __real_malloc has the same
signature of malloc.
If the signatures did match I probably could have done that.

https://codereview.chromium.org/1719433002/diff/140001/base/allocator/allocat...
base/allocator/allocator_shim_default_dispatch_to_linker_wrapped_symbols.cc:56:
nullptr,         /* next */
On 2016/04/08 20:23:07, Nico (hiding until Fri) wrote:
> nit: align

Oops. Done

[Primiano Tucci (use gerrit), 2016-04-11 13:49:21]

The CQ bit was checked by primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-04-11 13:49:21]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1719433002/#ps160001
(title: "Add readme changes, do NOT enabled by default in this cl")

[commit-bot: I haz the power, 2016-04-11 13:49:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1719433002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1719433002/160001

[commit-bot: I haz the power, 2016-04-11 14:47:36]

Description was changed from

==========
Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a 
bad state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a 
bad state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

[commit-bot: I haz the power, 2016-04-11 14:47:37]

Committed patchset #3 (id:160001)

[commit-bot: I haz the power, 2016-04-11 14:49:17]

Description was changed from

==========
Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a 
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003


Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).


Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried 
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path. 
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a 
bad state in these days.


BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*
==========

to

==========
Introduce allocator shim for Android

This is a follow-up to the work of crrev.com/1675143004 and ports the
shim layer to Android.
Conversely to Linux, on Android symbol interposition is not possible.
This is because Android processes are fork-ed from the Android zygote,
which pre-loads libc.so, and later native code gets dlopen-ed.
Therefore a different approach is used on Android, that is:
 - All linker units that depend on //base:allocator (via //base)
   get the --Wl,-wrap,malloc (& friends) linker flag.
 - Such linker flags causes all symbol references to malloc to be
   rewritten as references to __wrap_malloc.
- The __wrap_malloc & friends symbols are defined by
  allocator_shim_override_linker_wrapped_symbols.h. These symbols
  route the malloc calls inside the shim layer.
 - The shim layer ultimately dispatches the calls to the __real_malloc
   symbol.
 - The special __real_malloc symbols are resolved by the linker (as a
   result of -wrap) against what would have been the original "malloc"
   symbol.

In summary, this entire trickery is transparent to the dynamic loader,
which still sees undefined symbol references to malloc & friend symbols.
Those symbols will be resolved against libc.so (or whatever other weird
choice the Android OEM made) as usual.

An alternative approach would have been just redefining the malloc symbols
and use dlsym() to do the routing to bionic. This has the following
disadvantages:
 - More risky, as Chrome for Android has insane layers of complexity around
   loading (crazylinker pre M, relies on a special flavour of dlopen on M+).
 - Won't be possible to support component builds, as all components
   % libbase.so would resolve malloc against libc.so (unless violating ODR
   and redefining malloc & friends in every component, which smells bad++).

All this trickery is a noop when use_experimental_allocator_shim=false.
This CL does NOT enable the shim by default on Android. This will happen
separately in crrev.com/1875043003

Motivations of this work
------------------------
 - This allows the memory-infra heap-profiler to work on Android
   (design doc: https://goo.gl/UPfbF4).
 - This enables security checks (suicide on malloc()==null via
   the std::new_handler) on Android.
 - This fixes by accident crbug.com/598075 (Some Android device vendor
   forgot to implement posix_memalign on J, as mandated by the NDK,
   causing chrome to crash on startup).

Performance considerations
------------------------
Binary size diff (GN, arm, static, official build): 24k

I did a mixture of local and trybots run to estimate the perf impact
of this change. Didn't get any conclusive data, everything I tried
seems in the same ballpark, below noise levels. More in details:

cc_perftests.PrepareTiles on a Nexus 4.
Rationale of the choice: in a previous CL (crbug.com/593344), this
benchmark revealed the presence of two mfences in the malloc path.
Results: https://goo.gl/8VC3Jp in the same ballpark.

page-cycler on Nexus 9 via trybots:
Results: http://goo.gl/J3i50a seems to suggest that this CL improves
both warm and cold times in most cases. I doubt it, more likely it's
noise.

All the other perf trybots failed. The perf waterfall seems to be in a
bad state in these days.

BUG=550886,598075
TEST=base_unittests --gtest_filter=AllocatorShimTest.*

Committed: https://crrev.com/40b65c66b855b58cb2fda9228b7626f2904581a5
Cr-Commit-Position: refs/heads/master@{#386382}
==========

[commit-bot: I haz the power, 2016-04-11 14:49:20]

Patchset 3 (id:??) landed as
https://crrev.com/40b65c66b855b58cb2fda9228b7626f2904581a5
Cr-Commit-Position: refs/heads/master@{#386382}