arm: Use _dl_find_object on __gnu_Unwind_Find_exidx (BZ 31405)

  Instead of __dl_iterate_phdr. On ARM dlfo_eh_frame/dlfo_eh_count
maps to PT_ARM_EXIDX vaddr start / length.

On a Neoverse N1 machine with 160 cores, the following program:

  $ cat test.c
  #include <stdlib.h>
  #include <pthread.h>
  #include <assert.h>

  enum {
    niter = 1024,
    ntimes = 128,
  };

  static void *
  tf (void *arg)
  {
    int a = (int) arg;

    for (int i = 0; i < niter; i++)
      {
        void *p[ntimes];
        for (int j = 0; j < ntimes; j++)
  	p[j] = malloc (a * 128);
        for (int j = 0; j < ntimes; j++)
  	free (p[j]);
      }

    return NULL;
  }

  int main (int argc, char *argv[])
  {
    enum { nthreads = 16 };
    pthread_t t[nthreads];

    for (int i = 0; i < nthreads; i ++)
      assert (pthread_create (&t[i], NULL, tf, (void *) i) == 0);

    for (int i = 0; i < nthreads; i++)
      {
        void *r;
        assert (pthread_join (t[i], &r) == 0);
        assert (r == NULL);
      }

    return 0;
  }
  $ arm-linux-gnueabihf-gcc -fsanitize=address test.c -o test

Improves from ~15s to 0.5s.

Checked on arm-linux-gnueabihf.
---
 elf/Makefile             |  2 +-
 elf/dl-find_object.c     |  5 ++--
 include/dlfcn.h          |  3 ++-
 sysdeps/arm/find_exidx.c | 57 +++-------------------------------------
 4 files changed, 10 insertions(+), 57 deletions(-)
  

* Adhemerval Zanella:

> On a Neoverse N1 machine with 160 cores, the following program:

>     for (int i = 0; i < niter; i++)
>       {
>         void *p[ntimes];
>         for (int j = 0; j < ntimes; j++)
>   	p[j] = malloc (a * 128);
>         for (int j = 0; j < ntimes; j++)
>   	free (p[j]);
>       }
>
>     return NULL;
>   }

>   $ arm-linux-gnueabihf-gcc -fsanitize=address test.c -o test
>
> Improves from ~15s to 0.5s.

Is this specific to 32-bit Arm, or does _dl_find_object provide a
similar performance benefit to multi-threaded Address Sanitizer on
GCC 12 with glibc 2.35, too?  I didn't expect that.
  

On 22/02/24 11:54, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On a Neoverse N1 machine with 160 cores, the following program:
> 
>>     for (int i = 0; i < niter; i++)
>>       {
>>         void *p[ntimes];
>>         for (int j = 0; j < ntimes; j++)
>>   	p[j] = malloc (a * 128);
>>         for (int j = 0; j < ntimes; j++)
>>   	free (p[j]);
>>       }
>>
>>     return NULL;
>>   }
> 
>>   $ arm-linux-gnueabihf-gcc -fsanitize=address test.c -o test
>>
>> Improves from ~15s to 0.5s.
> 
> Is this specific to 32-bit Arm, or does _dl_find_object provide a
> similar performance benefit to multi-threaded Address Sanitizer on
> GCC 12 with glibc 2.35, too?  I didn't expect that.

This is ARM specific afaik, libgcc/unwind-arm-common.inc calls 
__gnu_Unwind_Find_exidx (if available) on _Unwind_Backtrace
call (pretty much like BZ 31405 first comment). And this has
not been changed for a while, so both gcc 12 and master uses the
same code.
  

* Adhemerval Zanella Netto:

> On 22/02/24 11:54, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> On a Neoverse N1 machine with 160 cores, the following program:
>> 
>>>     for (int i = 0; i < niter; i++)
>>>       {
>>>         void *p[ntimes];
>>>         for (int j = 0; j < ntimes; j++)
>>>   	p[j] = malloc (a * 128);
>>>         for (int j = 0; j < ntimes; j++)
>>>   	free (p[j]);
>>>       }
>>>
>>>     return NULL;
>>>   }
>> 
>>>   $ arm-linux-gnueabihf-gcc -fsanitize=address test.c -o test
>>>
>>> Improves from ~15s to 0.5s.
>> 
>> Is this specific to 32-bit Arm, or does _dl_find_object provide a
>> similar performance benefit to multi-threaded Address Sanitizer on
>> GCC 12 with glibc 2.35, too?  I didn't expect that.
>
> This is ARM specific afaik, libgcc/unwind-arm-common.inc calls 
> __gnu_Unwind_Find_exidx (if available) on _Unwind_Backtrace
> call (pretty much like BZ 31405 first comment). And this has
> not been changed for a while, so both gcc 12 and master uses the
> same code.

If Address Sanitizer calls _Unwind_Backtrace (perhaps via
libbacktrace) in malloc, this should impact DWARF targets as well: the
glibc 2.35/GCC 12 combination is more similar to Arm because the
dl_iterate_phdr call in the _Unwind_Backtrace implementation has been
replaced with _dl_find_object.

The patch is looks okay to me, by the way.  I had this in mind when
working on _dl_find_object, but couldn't test it at the time.
  

On 22/02/24 14:25, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 22/02/24 11:54, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On a Neoverse N1 machine with 160 cores, the following program:
>>>
>>>>     for (int i = 0; i < niter; i++)
>>>>       {
>>>>         void *p[ntimes];
>>>>         for (int j = 0; j < ntimes; j++)
>>>>   	p[j] = malloc (a * 128);
>>>>         for (int j = 0; j < ntimes; j++)
>>>>   	free (p[j]);
>>>>       }
>>>>
>>>>     return NULL;
>>>>   }
>>>
>>>>   $ arm-linux-gnueabihf-gcc -fsanitize=address test.c -o test
>>>>
>>>> Improves from ~15s to 0.5s.
>>>
>>> Is this specific to 32-bit Arm, or does _dl_find_object provide a
>>> similar performance benefit to multi-threaded Address Sanitizer on
>>> GCC 12 with glibc 2.35, too?  I didn't expect that.
>>
>> This is ARM specific afaik, libgcc/unwind-arm-common.inc calls 
>> __gnu_Unwind_Find_exidx (if available) on _Unwind_Backtrace
>> call (pretty much like BZ 31405 first comment). And this has
>> not been changed for a while, so both gcc 12 and master uses the
>> same code.
> 
> If Address Sanitizer calls _Unwind_Backtrace (perhaps via
> libbacktrace) in malloc, this should impact DWARF targets as well: the
> glibc 2.35/GCC 12 combination is more similar to Arm because the
> dl_iterate_phdr call in the _Unwind_Backtrace implementation has been
> replaced with _dl_find_object.

The _Unwind_Backtrace depends on then default unwind strategy (Fast/Slow) 
which can be overridden by a environment variable 
(fast_unwind_on_malloc={0,1}).

The fast unwinder strategy (which tries to work the callstack by parsing 
the frame pointer) usually works if you used only one compiler/mode  
building everything (for instance if you build everything with clang -marm); 
but it start to hit some corner cases when you mix compilers and modes:

compiler-rt/lib/sanitizer_common/sanitizer_flags.inc

 43 // ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1]
 44 // and fast-unwider is also unreliable with mixing arm and thumb code [2].
 45 // [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172
 46 // [2] https://bugs.llvm.org/show_bug.cgi?id=44158
 47 COMMON_FLAG(bool, fast_unwind_on_malloc,
 48             !(SANITIZER_LINUX && !SANITIZER_ANDROID && SANITIZER_ARM),
 49             "If available, use the fast frame-pointer-based unwinder on "
 50             "malloc/free.")

> 
> The patch is looks okay to me, by the way.  I had this in mind when
> working on _dl_find_object, but couldn't test it at the time.

Thanks, I will install it.