tsan symbols are broken with NASM

[Clément Bœsch]

Since the switch from YASM to NASM, thread sanitizer is unusable by default:

WARNING: ThreadSanitizer: data race (pid=21662)
  Read of size 8 at 0x7b9800003008 by main thread (mutexes: write M1355):
    #0 <null> <null> (libtsan.so.0+0x000000030111)
    #1 <null> <null> (ffmpeg+0x000000d5481f)
    #2 <null> <null> (ffmpeg+0x000000d054e1)
    #3 <null> <null> (ffmpeg+0x000000e134d7)
    #4 <null> <null> (ffmpeg+0x000000e13ba8)
    #5 <null> <null> (ffmpeg+0x000000a1553f)
    #6 <null> <null> (ffmpeg+0x000000a1609a)
    #7 <null> <null> (ffmpeg+0x00000050e4e4)
    #8 <null> <null> (ffmpeg+0x000000510bb5)
    #9 <null> <null> (ffmpeg+0x0000004d6d3b)
    #10 <null> <null> (libc.so.6+0x000000020439)

This may be related to the way NASM stores dwarf symbols.

Note: tested only with gcc-tsan.

Note: we probably need to open a ticket on the NASM bugtracker if it's concluded we didn't mixed up incompatible options in our build system. Still, I consider this a regression since NASM wasn't the default previously.

Workaround: use --x86asmexe=yasm.

[Balling]

Did you open the bug in NASM?

[Carl Eugen Hoyos]

How can I reproduce this (with nasm)?

[Clément Bœsch]

I cannot reproduce the issue anymore, so I suppose it was fixed at some point during these years. I should be able to drop YASM from my FATE instances now.