Workaround ARM tracing issues for non-component builds.

Workaround Android tracing issues for non-component builds.

On Android/ARM native allocation tracing has two issues:

1. When built in arm mode it crashes sooner or later when unwinding calls
   from JNI, see https://crbug.com/602701#c18

2. When built in thumb mode unwinding simply doesn't work because stack
   frames are not stable, and there can be arbitrary number of registers
   between r7 and lr, see https://llvm.org/bugs/show_bug.cgi?id=18505#c5

This change fixes both issues in non-component builds by relying on a fact
that all Chrome code lives in a single mapped region. So there is a simple
and fast way to check whether given PC is from Chrome. That check is used
to solve both issues:

1. In arm mode unwinding stops as soon as first non-Chrome PC is detected.
   System libraries on both Linux and Android are built without frame
   pointers anyway, so there is no point in unwinding further.

2. In thumb mode, where lr (r14) register can be up to 7 registers away
   from r7 on the stack, lr is searched by probing each possible value to
   be inside Chrome's code region. This method sometimes finds false positives
   (which symbolize to things like $d.232), but overall works well and produces
   readable traces. Note that this is only applicable for Clang, because in GCC
   builds even r7 is not set up correctly.

BUG=602701

[Dmitry Skiba, 2016-05-20 05:03:41]

Description was changed from

==========
Workaround ARM tracing issues for non-component builds.

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

to

==========
Workaround Android tracing issues for non-component builds.

On Android/ARM native allocation tracing has two issues:

1. When built in arm mode it crashes sooner or later when unwinding calls
   from JNI, see crbug.com/602701#c18

2. When built in thumb mode unwinding simply doesn't work because stack
   frames are not stable, and there can be arbitrary number of registers
   between r7 and lr, see https://llvm.org/bugs/show_bug.cgi?id=18505#c5

This change fixes both issues in non-component builds by relying on a fact
that all Chrome code lives in a single mapped region. So there is a simple
and fast way to check whether given PC is from Chrome. That check is used
to solve both issues:

1. In arm mode unwinding stops as soon as first non-Chrome PC is detected.
   System libraries on both Linux and Android are built without frame
   pointers anyway, so there is no point in unwinding further.

2. In thumb mode, where lr (r14) register can be up to 7 registers away
   from r7 on the stack, lr is searched by probing each possible value to
   be inside Chrome's code region. This method sometimes finds false positives
   (which symbolize to things like $d.232), but overall works well and produces
   readable traces. Note that this is only applicable for Clang, because in GCC
   builds even r7 is not set up correctly.

BUG=602701
==========

[Dmitry Skiba, 2016-05-20 05:04:11]

Description was changed from

==========
Workaround Android tracing issues for non-component builds.

On Android/ARM native allocation tracing has two issues:

1. When built in arm mode it crashes sooner or later when unwinding calls
   from JNI, see crbug.com/602701#c18

2. When built in thumb mode unwinding simply doesn't work because stack
   frames are not stable, and there can be arbitrary number of registers
   between r7 and lr, see https://llvm.org/bugs/show_bug.cgi?id=18505#c5

This change fixes both issues in non-component builds by relying on a fact
that all Chrome code lives in a single mapped region. So there is a simple
and fast way to check whether given PC is from Chrome. That check is used
to solve both issues:

1. In arm mode unwinding stops as soon as first non-Chrome PC is detected.
   System libraries on both Linux and Android are built without frame
   pointers anyway, so there is no point in unwinding further.

2. In thumb mode, where lr (r14) register can be up to 7 registers away
   from r7 on the stack, lr is searched by probing each possible value to
   be inside Chrome's code region. This method sometimes finds false positives
   (which symbolize to things like $d.232), but overall works well and produces
   readable traces. Note that this is only applicable for Clang, because in GCC
   builds even r7 is not set up correctly.

BUG=602701
==========

to

==========
Workaround Android tracing issues for non-component builds.

On Android/ARM native allocation tracing has two issues:

1. When built in arm mode it crashes sooner or later when unwinding calls
   from JNI, see https://crbug.com/602701#c18

2. When built in thumb mode unwinding simply doesn't work because stack
   frames are not stable, and there can be arbitrary number of registers
   between r7 and lr, see https://llvm.org/bugs/show_bug.cgi?id=18505#c5

This change fixes both issues in non-component builds by relying on a fact
that all Chrome code lives in a single mapped region. So there is a simple
and fast way to check whether given PC is from Chrome. That check is used
to solve both issues:

1. In arm mode unwinding stops as soon as first non-Chrome PC is detected.
   System libraries on both Linux and Android are built without frame
   pointers anyway, so there is no point in unwinding further.

2. In thumb mode, where lr (r14) register can be up to 7 registers away
   from r7 on the stack, lr is searched by probing each possible value to
   be inside Chrome's code region. This method sometimes finds false positives
   (which symbolize to things like $d.232), but overall works well and produces
   readable traces. Note that this is only applicable for Clang, because in GCC
   builds even r7 is not set up correctly.

BUG=602701
==========

[Dmitry Skiba, 2016-05-20 05:06:00]

dskiba@google.com changed reviewers:
+ primiano@chromium.org, thakis@chromium.org

[Dmitry Skiba, 2016-05-20 05:06:01]

PTAL, alternative to https://codereview.chromium.org/1975393002/

[Primiano Tucci (use gerrit), 2016-05-20 14:21:13]

On 2016/05/20 05:06:01, Dmitry Skiba wrote:
> PTAL, alternative to https://codereview.chromium.org/1975393002/

Thanks for looking at this. See my comment in the bug. I much more prefer
https://codereview.chromium.org/1975393002/
Rationale:
1. there is precedence (and opportunity for code sharing) in oilpan. 
2. Checking that a PC is inside the FP doesn't guarantee you that following the
FP chain is going to not segfault.
Also, purely from a code viewpoint, this one seems to bake lot of complex logic
inside of chrome and make lot of pretty strong assumptions (name of the .so, the
fact that you can read /proc/self/maps). For instance, in the case of bpf
sandbox you'll no longer be able to read maps, so this will have a rather short
life.

[Dmitry Skiba, 2016-05-20 17:03:16]

On 2016/05/20 14:21:13, Primiano Tucci wrote:
> On 2016/05/20 05:06:01, Dmitry Skiba wrote:
> > PTAL, alternative to https://codereview.chromium.org/1975393002/
> 
> Thanks for looking at this. See my comment in the bug. I much more prefer
> https://codereview.chromium.org/1975393002/
> Rationale:
> 1. there is precedence (and opportunity for code sharing) in oilpan. 
> 2. Checking that a PC is inside the FP doesn't guarantee you that following
the
> FP chain is going to not segfault.
> Also, purely from a code viewpoint, this one seems to bake lot of complex
logic
> inside of chrome and make lot of pretty strong assumptions (name of the .so,
the
> fact that you can read /proc/self/maps). For instance, in the case of bpf
> sandbox you'll no longer be able to read maps, so this will have a rather
short
> life.

Agree, lets focus on the other CL.