[Bug build/27558] vsprintf() contains function alias with __asm__ label after first use

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27558

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> It fixes the issue but there is another problem now which indicates that we
> need to link against libatomic:
> 
> [9/4273] Linking CXX shared library
> lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so
> FAILED: lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so 
> : && /home/glaubitz/llvm-project/build/./bin/clang++ -fPIC -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
> -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default
> -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wsuggest-override -Wstring-conversion -Werror=return-type
> -fdiagnostics-color -Wall -std=c++14 -Wno-unused-parameter -g  -Wl,-z,defs
> -Wl,-z,nodelete   -m32 -nodefaultlibs -Wl,-z,text -nostdlib++
> -Wl,-rpath-link,/home/glaubitz/llvm-project/build/tools/clang/stage2-bins/./
> lib -shared -Wl,-soname,libclang_rt.ubsan_minimal-sparc.so -o
> lib/clang/13.0.0/lib/linux/libclang_rt.ubsan_minimal-sparc.so
> projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/
> ubsan_minimal_handlers.cpp.o  -Wl,-rpath,"\$ORIGIN/../lib"  -lgcc_s  -lc && :
> /usr/bin/ld:
> projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.sparc.dir/
> ubsan_minimal_handlers.cpp.o: in function `report_this_error(void*)':
> /home/glaubitz/llvm-project/compiler-rt/lib/ubsan_minimal/../
> sanitizer_common/sanitizer_atomic_clang.h:80: undefined reference to
> `__atomic_compare_exchange_4'
> clang-13: error: linker command failed with exit code 1 (use -v to see
> invocation)
> 
> I think, however, that this issue is unrelated.

About this issue, the missing proper atomic on sparcv8 has causes some issue in
glibc and required us to add a similar trick to emulate atomic operations that
has its own drawbacks (no async-signal-safe, a lot of contention).

On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported,
but only if the optional CAS instruction is implemented (for instance, LEON
processors, but SuperSPARC processors are not).  So maybe one option is to
limit build for SPARC ISA v9.

-- 
You are receiving this mail because:
You are on the CC list for the bug.