[PATCH] D29586: [lsan] Enable LSan for arm Linux

[Maxim Ostapenko via Phabricator via llvm-commits]

m.ostapenko added a comment.

In https://reviews.llvm.org/D29586#672380, @zatrazz wrote:

> In https://reviews.llvm.org/D29586#672157, @m.ostapenko wrote:
>
> > In https://reviews.llvm.org/D29586#668769, @m.ostapenko wrote:
> >
> > > In https://reviews.llvm.org/D29586#668050, @rengolin wrote:
> > >
> > > > You seem to be enabling it on soft and hard float. Did you test on both environments? What type of hardware did you test this?
> > >
> > >
> > > I've tested the patch on two configurations:
> > >
> > > 1. Linaro Ubuntu 14.04 (Trusty) on Arndale board. It's a hard float system, right?
> >
> >
> > Oh, things become more complicated... I see many test failures with host GCC 4.8 because fast unwinder failed to get backtraces for mallocs. This happens because **__interceptor_malloc**, compiled by GCC 4.8, didn't properly save **frame pointer register**:
> >
> >   00000000 <__interceptor_malloc>:
> >      0:   e92d 47f0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, sl, lr}
> >      4:   f5ad 6d85       sub.w   sp, sp, #1064   ; 0x428
> >      8:   4d29            ldr     r5, [pc, #164]  ; (b0 <__interceptor_malloc+0xb0>)
> >      a:   4b2a            ldr     r3, [pc, #168]  ; (b4 <__interceptor_malloc+0xb4>)
> >      c:   af04            add     r7, sp, #16
> >      e:   447d            add     r5, pc
> >
> >
> > But if compile with clang (3.3, 3.5 or trunk) or GCC 4.9, the fp is saved properly:
> >
> >   00000000 <__interceptor_malloc>:
> >      0:   e92d4ff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
> >      4:   e28db01c        add     fp, sp, #28
> >      8:   e24dd024        sub     sp, sp, #36     ; 0x24
> >      c:   e24ddb01        sub     sp, sp, #1024   ; 0x400
> >     10:   e1a08000        mov     r8, r0
> >
> >
> > So, it seems that LSan's operability depends on what compiler is used to build it :(.
>
>
> It is a know issue [1] [2] and in fact it a little more complicated, it depends on the flags used as well:
>
>   if you mix thumb and arm code fast unwinder won't work. I am not sure which option would be better, 
>
> but I am afraid to get a reliable stacktrack on arm (with mixed objects and function built with different compilers)
>  we will need to use a external unwinder (maybe libunwinder). But it will have the side-effect of making 
>  backtrace way slower.
>
> [1] https://llvm.org/bugs/show_bug.cgi?id=22741
>  [2] https://llvm.org/bugs/show_bug.cgi?id=18505


Right, but I thought it affects only Thumb (that might be mixed with arm) but it seems that even arm mode is affected depending on GCC version. This complicates enabling tests on arm targets, but still, It would be nice to have LSan available on arm.


Repository:
  rL LLVM

https://reviews.llvm.org/D29586