[new subject. was: libsanitizer merge from upstream r196090]

>> .cfi is used only in tsan sources now, and tsan is not supported
>> anywhere but x86_64
>
> But the .cfi_* issue is platform independent.  Whether the compiler
> decides to emit them or not depends on how it was configured, on assembler
> and on compiler flags.
> I don't see how it can be a maintainance problem to just guard the few
> (right now two) .cfi_* occurrences in the C++ sources, or using CFI_* macros
> instead of .cfi_* directives directly in the assembly file.
> Other projects (e.g. glibc) manage to do that for years without any trouble.

This is a maintenance problem because we can not test if we broke
something during development.
e.g. clang doesn't seem to support -fno-dwarf2-cfi-asm
Then, if we get notified about the problem we spend 10x more time
fixing it because
1. the context is different
2. the patch you or other GCC folks send applies to GCC tree while we
need to apply it to LLVM
  (e.g. your patch has tsan/tsan_rtl.h but our tree has
tsan/rtl/tsan_rtl.h and even with that fixed it does not apply)
3. we still can't easily verify the fix.

I can commit a change similar to your cfi-related changes
(guarded by SANITIZER_DONT_USE_CFI_ASM instead of
__GCC_HAVE_DWARF2_CFI_ASM), but the problem will arise again

--kcc

Reply via email to