Add a stub __cxa_demangle to disable LLVM's demangler.

Add a stub __cxa_demangle to disable LLVM's demangler.

LLVM's demangler is fairly large and included by default in linked
binaries.  Chromium's demangling happens on host systems when needed,
so demangling code is not required on the target.

Supplying our own stub function stops the linker pulling in the LLVM
demangler from libc++, and reduces the size of libchrome.so accordingly.

Results from a Release build:
  Before:
    $ size --format=SysV out/Release/chrome_apk/libs/armeabi-v7a/libchrome.so
    section                      size       addr
    ...
    .text                    26210064    2237952
    ...
    Total                    35736055
  After:
    $ size --format=SysV out/Release/chrome_apk/libs/armeabi-v7a/libchrome.so
    section                      size       addr
    ...
    .text                    26007820    2237888
    ...
    Total                    35523543

BUG=485154
Committed: https://crrev.com/0e736a812b7aa3f3e1643929e4d0893122b70989
Cr-Commit-Position: refs/heads/master@{#336765}

[simonb (inactive), 2015-06-26 11:42:15]

simonb@chromium.org changed reviewers:
+ andrewhayden@chromium.org, rmcilroy@chromium.org, thakis@chromium.org

[Andrew Hayden (chromium.org), 2015-06-26 12:00:54]

LGTM! Thanks.

[rmcilroy, 2015-06-26 12:43:49]

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
File base/android/cxa_demangle_stub.cc (right):

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
base/android/cxa_demangle_stub.cc:15: static const int kMemoryAllocFailure = -1;
 // LLVM's memory_alloc_failure.
Can we just do a CHECK(false) here instead? This would make it more obvious if
someone were to introduce a dependency on cxa_demangler as to what was going
wrong. 

Also, should we do this for all Posix platforms that pull in libc++,  or are
there requirements on cxa_demangler on other platforms?

[simonb (inactive), 2015-06-26 15:00:09]

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
File base/android/cxa_demangle_stub.cc (right):

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
base/android/cxa_demangle_stub.cc:15: static const int kMemoryAllocFailure = -1;
 // LLVM's memory_alloc_failure.
On 2015/06/26 12:43:49, rmcilroy wrote:
> Can we just do a CHECK(false) here instead? This would make it more obvious if
> someone were to introduce a dependency on cxa_demangler as to what was going
> wrong.

I'm pretty sure we don't want to CHECK(false) here.  If LLVM or something else
calls this we don't want to crash, just indicate that demangling is effectively
disabled.  LLVM already has a dependency on it, which is why the code is drawn
in from libc++.  What we want to do is lighten the implementation while leaving
it still functional.

See the parallel PNaCl change:
https://codereview.chromium.org/102883003

> 
> Also, should we do this for all Posix platforms that pull in libc++,  or are
> there requirements on cxa_demangler on other platforms?

Our requirement is to keep libchrome slim on Android.  Extending it to other
posix may be possible/desirable, but these aren't environments we generally work
in.

[Nico, 2015-06-26 17:13:13]

lgtm!

[rmcilroy, 2015-06-29 09:24:18]

lgtm.

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
File base/android/cxa_demangle_stub.cc (right):

https://codereview.chromium.org/1215673002/diff/1/base/android/cxa_demangle_s...
base/android/cxa_demangle_stub.cc:15: static const int kMemoryAllocFailure = -1;
 // LLVM's memory_alloc_failure.
On 2015/06/26 15:00:09, simonb wrote:
> On 2015/06/26 12:43:49, rmcilroy wrote:
> > Can we just do a CHECK(false) here instead? This would make it more obvious
if
> > someone were to introduce a dependency on cxa_demangler as to what was going
> > wrong.
> 
> I'm pretty sure we don't want to CHECK(false) here.  If LLVM or something else
> calls this we don't want to crash, just indicate that demangling is
effectively
> disabled.  LLVM already has a dependency on it, which is why the code is drawn
> in from libc++.  What we want to do is lighten the implementation while
leaving
> it still functional.
> 
> See the parallel PNaCl change:
> https://codereview.chromium.org/102883003
> 

Ok sounds good, thanks for the explanation.
> > Also, should we do this for all Posix platforms that pull in libc++,  or are
> > there requirements on cxa_demangler on other platforms?
> 
> Our requirement is to keep libchrome slim on Android.  Extending it to other
> posix may be possible/desirable, but these aren't environments we generally
work
> in.

Fair enough.

[simonb (inactive), 2015-06-30 10:25:34]

The CQ bit was checked by simonb@chromium.org

[commit-bot: I haz the power, 2015-06-30 10:26:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1215673002/1

[commit-bot: I haz the power, 2015-06-30 11:34:40]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-06-30 11:35:34]

Patchset 1 (id:??) landed as
https://crrev.com/0e736a812b7aa3f3e1643929e4d0893122b70989
Cr-Commit-Position: refs/heads/master@{#336765}