libsanitizer merge from upstream r191666

Konstantin Serebryany konstantin.s.serebryany@gmail.com
Fri Nov 15 16:35:00 GMT 2013


On Fri, Nov 15, 2013 at 6:33 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Nov 15, 2013 at 06:12:07PM +0400, Konstantin Serebryany wrote:
>> I afraid it actually wants the header (magic, descr, pc) to be in the
>> first 3 words in the
>> memory returned by __asan_stack_malloc_*
>> FakeStack::AddrIsInFakeStack(addr) returns the beginning of the allocated chunk
>> and then AsanThread::GetFrameNameByAddr expects the header to be there.
>
> Can it be changed?

Maybe, but not like this.
For fake stack, when the frame is already dead, the shadow will have
different value
(kAsanStackAfterReturnMagic) and the checks (*shadow_ptr ==
kAsanStackLeftRedzoneMagic) will not work

If we do this, we'll need to test very very carefully.
This thing is too subtle -- it required a few attempts to get right.
So I'd prefer not to.

Why can't we create the redzone of max(32, alignment) bytes?


> I mean, adding potentially very large first red zone
> would be quite expensive, and would have to be done unconditionally, even
> when not using fake stacks.
>
> I mean, in AsanThread::GetFrameNameByAddr do (pseudo patch):
> +  u8 *shadow_bottom;
>    if (AddrIsInStack(addr)) {
>      bottom = stack_bottom();
> +    shadow_bottom = (u8*)MemToShadow(bottom);
>    } else if (has_fake_stack()) {
>      bottom = fake_stack()->AddrIsInFakeStack(addr);
>      CHECK(bottom);
> -    *offset = addr - bottom;
> -    *frame_pc = ((uptr*)bottom)[2];
> -    return  (const char *)((uptr*)bottom)[1];
> +    shadow_bottom = (u8*)MemToShadow(bottom);
> +    if (*shadow_bottom == kAsanStackLeftRedzoneMagic) {
> +      *offset = addr - bottom;
> +      *frame_pc = ((uptr*)bottom)[2];
> +      return  (const char *)((uptr*)bottom)[1];
> +    }
>    }
>    uptr aligned_addr = addr & ~(SANITIZER_WORDSIZE/8 - 1);  // align addr.
>    u8 *shadow_ptr = (u8*)MemToShadow(aligned_addr);
> -  u8 *shadow_bottom = (u8*)MemToShadow(bottom);
>
>
>         Jakub



More information about the Gcc-patches mailing list