[PATCH] Test failures in GCC ASan testsuite on ARM Linux due to FP format mismatch between libsanitizer and GCC.

[Yury Gribov]

================
Comment at: lib/sanitizer_common/sanitizer_stacktrace.cc:65
@@ -44,3 +64,3 @@
   size = 1;
-  uhwptr *frame = (uhwptr *)bp;
-  uhwptr *prev_frame = frame - 1;
+  stack_bottom = Max(stack_bottom, (uptr)&size);
+  uhwptr *frame = GetCanonicFrame(bp, stack_top, stack_bottom);
----------------
Alexey Samsonov wrote:
> Yury Gribov wrote:
> > Maxim Ostapenko wrote:
> > > Alexey Samsonov wrote:
> > > > This line is wrong. It assumes that FastUnwindStack() is called in the same thread for which we provide stack_top/stack_bottom. I believe this function describes a generic unwinding algorithm, and there's no place for hack like this here.
> > > > 
> > > > Why do you need it?
> > > Hm, stack_bottom is simply stack_top - kStackSize (8 MB), isn't it? So, we have 8 MB interval for "valid" stack addresses. But in Linux stack grows dynamically, so if access address is, for example, in the middle of this interval, this can cause a segmentation fault, because libc hasn't mapped this memory yet. So we need something like this to prevent this error. You are right, this will work only in case if FastUnwindStack() is called in the same thread for which we provide stack_top/stack_bottom, but if it is called in another thread, how can we implement such kind of protection?
> > Can we do stack_bottom = Max(stack_bottom, bp) instead?
> Stack size is not always 8Mb, it's configurable in many ways. And, yes, it grows dynamically. But we don't assume that the whole interval from stack_top to stack_bottom is accessible. We would access unmapped memory only if there's a bug in unwinding algorithm or the frame pointers are broken. Do you actually observe such cases?
We could also access unmapped area if code was compiled without fp support. And yes, we saw this in our ARM tests.

http://reviews.llvm.org/D4692