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

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

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 27558
           Summary: vsprintf() contains function alias with __asm__ label
                    after first use
           Product: glibc
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: adhemerval.zanella at linaro dot org, carlos at redhat dot com,
                    ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com
  Target Milestone: ---

When building stage2 with clang on sparc64, the build fails with [1]:

In file included from
/var/lib/buildbot/workers/debian-stadler-sparc64/clang-sparc64-linux-multistage/llvm/compiler-rt/lib/sanitizer_common/sanitizer_stackdepot.cpp:17:
In file included from
/var/lib/buildbot/workers/debian-stadler-sparc64/clang-sparc64-linux-multistage/llvm/compiler-rt/lib/sanitizer_common/sanitizer_stackdepotbase.h:16:
In file included from /usr/include/stdio.h:870:
/usr/include/bits/stdio-ldbl.h:26:20: error: cannot apply asm label to function
after its first use
__LDBL_REDIR_DECL (vfprintf)
~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/usr/include/sys/cdefs.h:467:26: note: expanded from macro '__LDBL_REDIR_DECL'
  extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
                         ^           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

After some research, it turned out to be a bug in glibc which triggers an error
in clang [2] but not gcc. According to the discussion in [2], the different
behavior of clang compared to gcc is intentional and the pattern in question
should actually not exist anymore in glibc. According to the discussion in [1],
the bug triggers on sparc* only since there is no long double math
(__NO_LONG_DOUBLE_MATH) on this target.

> [1] https://bugs.llvm.org/show_bug.cgi?id=48650
> [2] https://bugs.llvm.org/show_bug.cgi?id=22830

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

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

[jrtc27 at jrtc27 dot com]

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

--- Comment #1 from Jessica Clarke <jrtc27 at jrtc27 dot com> ---
To clarify: sparc64 has long double, but sparc does not (although perhaps
sparcv8plus might have it as an option given it's there in the hardware).

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

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

[adhemerval.zanella at linaro dot org]

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

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
If I understood correctly the issue is asm alias is declared *after* the
function prototype, right? Does the fix from
https://bugs.llvm.org/show_bug.cgi?id=48650#c4 fix the issue without any
regression?

If so I can check if it breaks anything on other architectures and prepare a
patch.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
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.

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

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

[adhemerval.zanella at linaro dot 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.

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
> On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported

That's surprising news to me.

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

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

[adhemerval.zanella at linaro dot org]

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

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> > On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported
> 
> That's surprising news to me.

It is on the NEWS file at 'Deprecated and removed features, and other changes
affecting compatibility:'.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Adhemerval Zanella from comment #6)
> (In reply to John Paul Adrian Glaubitz from comment #5)
> > > On glibc 2.31, SPARC ISA v7 is no longer supported and v8 is still supported
> > 
> > That's surprising news to me.
> 
> It is on the NEWS file at 'Deprecated and removed features, and other
> changes affecting compatibility:'.

Sure, but I'm surprised that there was no prior discussion to that as both GCC
and the Linux kernel support SPARC V7, so the removal is rather unfortunate ...

But we should not hijack this thread for that. Either way, the suggested change
fixes this problem for me.

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

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

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 10 Mar 2021, glaubitz at physik dot fu-berlin.de via Glibc-bugs wrote:

> Sure, but I'm surprised that there was no prior discussion to that as both GCC
> and the Linux kernel support SPARC V7, so the removal is rather unfortunate ...

It was discussed on libc-alpha in November 2019.

In practice, the SPARC V7 support had been broken for a long time before 
then (the original patch submission says glibc 2.23 / commit 
b02840bacdefde318d2ad2f920e50785b9b25d69).  So I think the removal was 
similar in spirit to the removal of support for the original i386 (de 
facto unsupported from glibc 2.4 onwards / the introduction of NPTL, but 
it was some years after that before all the i386 code was removed and i486 
files moved into the generic i386 locations), which was also about lack of 
sufficient atomic operations support.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
@Adhemerval: In any case, could you try the suggested change and apply it if
it's fine?

I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> @Adhemerval: In any case, could you try the suggested change and apply it if
> it's fine?
> 
> I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC.

Ping. Would be great if we could get this fixed as the suggested fix works for
me.

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

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

[adhemerval.zanella at linaro dot org]

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

--- Comment #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to John Paul Adrian Glaubitz from comment #9)
> > @Adhemerval: In any case, could you try the suggested change and apply it if
> > it's fine?
> > 
> > I would then go ahead and raise the baseline for compiler-rt on 32-bit SPARC.
> 
> Ping. Would be great if we could get this fixed as the suggested fix works
> for me.

I didn't have time to prepare a patch, if you could send it to libc-alpha I can
check and review it.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #12 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Adhemerval Zanella from comment #11) 
> I didn't have time to prepare a patch, if you could send it to libc-alpha I
> can check and review it.

Done: https://sourceware.org/pipermail/libc-alpha/2021-March/124254.html

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Any news on this particular issue? The problem still causes LLVM stage2 failing
to build on sparc64 in the LLVM CI.

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

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

[fw at deneb dot enyo.de]

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

Florian Weimer <fw at deneb dot enyo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-
                 CC|                            |fw at deneb dot enyo.de

--- Comment #14 from Florian Weimer <fw at deneb dot enyo.de> ---
There seems to be unaddressed feedback on the mailing list:
https://sourceware.org/pipermail/libc-alpha/2021-March/124313.html

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #15 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
FWIW, Adhemerval has a branch on his Github account which is supposed to
address this issue:

> https://github.com/zatrazz/glibc/tree/azanella/redir-refactor

I haven't been able to test the changes yet, i.e. it didn't work for me for
unrelated reasons.

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

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #16 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I think this has been fixed in [1] and this bug can be closed.

> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=d0fa09a7701956036ff36f8ca188e9fff81553d8

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