[all-commits] [llvm/llvm-project] c584c4: [asan] Speed up ASan ODR indicator-based checking ...

Artem Pianykh via All-commits all-commits at lists.llvm.org
Thu Aug 1 13:58:37 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c584c4227105c2aae332ee2a2099c9df6c3a3e1c
      https://github.com/llvm/llvm-project/commit/c584c4227105c2aae332ee2a2099c9df6c3a3e1c
  Author: Artem Pianykh <arr at fb.com>
  Date:   2024-08-01 (Thu, 01 Aug 2024)

  Changed paths:
    M compiler-rt/lib/asan/asan_globals.cpp
    A compiler-rt/test/asan/TestCases/Linux/odr_indicator_unregister.cpp

  Log Message:
  -----------
  [asan] Speed up ASan ODR indicator-based checking (#100923)

**Summary**:
When ASan checks for a potential ODR violation on a global it loops over
a linked list of all globals to find those with the matching value of an
indicator. With the default setting 'detect_odr_violation=1', ASan
doesn't report violations on same-size globals but it still has to
traverse the list. For larger binaries with a ton of shared libs and
globals (and a non-trivial volume of same-sized duplicates) this gets
extremely expensive.

This patch adds an indicator indexed (multi-)map of globals to speed up
the search.

> Note: asan used to use a map to store globals a while ago which was
replaced with a list when the codebase [moved off of
STL](https://github.com/llvm/llvm-project/commit/e4bada2c946e5399fc37bd67421de01c0047ad38).

Internally we see many examples where ODR checking takes *seconds* (even
double digits). With this patch it's practically free and
`__asan_register_globals` doesn't show up prominently in the perf
profile anymore.

There are several high-level questions:
1. I understand that the intent is that we hit the slow path rarely,
ideally once before the process dies with an error. But in practice we
hit the slow path a lot. It feels reasonable to keep the amount of work
bounded even in the worst case, even if it requires a bit of extra
memory. But if not, it'd be great to learn about the tradeoffs.
2. Poisoning based ODR checking remains on the slow path. Internally we
build everything with `-fsanitize-address-use-odr-indicator` so I'm not
sure if poisoning-based check would exhibit the same behavior (looking
at the code, the shape looks very similar, so it might?).
3. Globals with an ODR indicator of `-1` need to be skipped for the
purposes of ODR checking (cf.
https://github.com/llvm/llvm-project/commit/a257639a6935a2c63377784c5c9c3b73864a2582).
But they are still getting added to the list of globals and hence take
up space and slow down the iteration over the list of globals. It would
be a good saving if we could avoid adding them to the globals list.
4. Any reason to use a linked list instead of e.g. a vector to store
globals?

**Test Plan**:

* `cmake --build build --target check-asan` looks good
* Perf-wise things look good when linking against this version of
compiler-rt.

---------

Co-authored-by: Vitaly Buka <vitalybuka at google.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list