Properly linking a shared library with -shared-libasan

MLIR
#1

I’ve recently found that in order to use ASAN on MLIR python extensions, I have to link the common CAPI .so with -shared-asan (and then do the dance to LD_PRELOAD the right library when invoking Python) in order to avoid link errors in MLIR. While just hacking privately, I did this by adding this to add_mlir_aggregate:

target_link_options(${name} PRIVATE -shared-libasan)

I could have sworn this used to work (without that). I went searching through the codebase to see where else we add -shared-libasan and couldn’t find anything. I know @mehdi_amini has gotten this working before and I wonder if there is any state I am missing?

I’m on clang12. I’ve only previously used ASAN with Python extensions with gcc, so I suspect that might be part of the different experience. I’m not an ASAN expert…

#2

I haven’t used -shared-libasan so far, what are the symptoms when we don’t use it? (I don’t quite get what it does or why it is needed when we use LD_PRELOAD)

#3

It gets linker errors on a long list of asan symbols at link time of that shared library – and putting those in to Google led me to various answers that said to use -shared-asan. That is all I know right now :slight_smile:

I suspect that something changed here with clang 12 because I don’t think I had to do this before. But just going on memory.

#4

This, from the clang docs, seems to be the answer: “When linking shared libraries, the AddressSanitizer run-time is not linked, so -Wl,-z,defs may cause link errors (don’t use it with AddressSanitizer).”

1 Like
#5

My ASAN bot is testing with clang-12 and the python bindings are enabled: Buildbot