[Bug libc/31655] New: clang can't build glibc with stack protector

[Bug libc/31655] New: clang can't build glibc with stack protector

[hjl.tools at gmail dot com]

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

            Bug ID: 31655
           Summary: clang can't build glibc with stack protector
           Product: glibc
           Version: 2.40
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: hjl.tools at gmail dot com
                CC: adhemerval.zanella at linaro dot org, drepper.fsp at gmail dot com,
                    skpgkp2 at gmail dot com
  Target Milestone: ---
            Target: x86

On x86, glibc built with stack protector using clang crashed very early:

(gdb) bt
#0 0x00000000005b3327 in bsearch (__key=__key@entry=0x7fffffffe540,
__base=0x6bde70 <intel_02_known>, __nmemb=__nmemb@entry=68,
__size=__size@entry=8,
__compar=__compar@entry=0x5b2400 <intel_02_known_compare>) at
../bits/stdlib-bsearch.h:22
#1 0x00000000005b220a in intel_check_word (name=name@entry=188, value=16711424,
has_level_2=has_level_2@entry=0x7fffffffe587,
no_level_2_or_3=no_level_2_or_3@entry=0x7fffffffe586, cpu_features=)
at ../sysdeps/x86/dl-cacheinfo.h:217
#2 0x00000000005b1904 in handle_intel (name=name@entry=188, cpu_features=)
at ../sysdeps/x86/dl-cacheinfo.h:279
#3 0x00000000005b0606 in dl_init_cacheinfo (cpu_features=)
at ../sysdeps/x86/dl-cacheinfo.h:811
#4 init_cpu_features (cpu_features=) at ../sysdeps/x86/cpu-features.c:1030
#5 __libc_start_main_impl (main=0x4599c0

, argc=13, argv=0x7fffffffe718,
init=, fini=, rtld_fini=0x0, stack_end=0x7fffffffe708)
at ../csu/libc-start.c:269
#6 0x0000000000401201 in _start () at ../sysdeps/x86_64/start.S:115
(gdb)

since the stack-protector canary in TCB hasn't been set up yet.
bits/stdlib-bsearch.h has an __extern_inline bsearch which is protected by

#ifdef __USE_EXTERN_INLINES
# include <bits/stdlib-bsearch.h>
#endif

But __USE_EXTERN_INLINES isn't defined for clang when building glibc on
azanella/clang branch:

/* Decide whether we can define 'extern inline' functions in headers.  */
#if __GNUC_PREREQ (2, 7) && defined __OPTIMIZE__ \
    && !defined __OPTIMIZE_SIZE__ && !defined __NO_INLINE__ \
    && defined __extern_inline && !(defined __clang__ && defined _LIBC)
# define __USE_EXTERN_INLINES   1
#endif

As the result, clang can't build glibc with stack protector on x86.

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

[Bug libc/31655] clang can't build glibc with stack protector

[adhemerval.zanella at linaro dot org]

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

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Right, I have not seen this issue because the box I use is an AMD one (which
never triggers handle_intel). I will check this out on a Intel box.

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

[Bug libc/31655] clang can't build glibc with stack protector

[skpgkp1 at gmail dot com]

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

skpgkp1 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skpgkp1 at gmail dot com

--- Comment #2 from skpgkp1 at gmail dot com ---
Created attachment 15472
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15472&action=edit
Fixes early startup crash.

There is difference between gcc and clang compiler as described in following
bug report.

https://bugs.llvm.org/show_bug.cgi?id=33926

If glibc build with option -Wno-error=ignored-attributes, it fixes the early
startup crash.

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

[Bug libc/31655] clang can't build glibc with stack protector

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to skpgkp1 from comment #2)
> Created attachment 15472 [details]
> Fixes early startup crash.
> 
> There is difference between gcc and clang compiler as described in following
> bug report.
> 
> https://bugs.llvm.org/show_bug.cgi?id=33926
> 
> If glibc build with option -Wno-error=ignored-attributes, it fixes the early
> startup crash.

Does it work without -Wno-error=ignored-attributes?

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

[Bug libc/31655] clang can't build glibc with stack protector

[adhemerval.zanella at linaro dot org]

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

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I think we make explicit the constraints in the code, where we can't call
external symbols in static build.  Something like:

diff --git a/sysdeps/x86/dl-cacheinfo.h b/sysdeps/x86/dl-cacheinfo.h
index 5a98f70364..1943dc7db6 100644
--- a/sysdeps/x86/dl-cacheinfo.h
+++ b/sysdeps/x86/dl-cacheinfo.h
@@ -98,6 +98,12 @@ static const struct intel_02_cache_info

 #define nintel_02_known (sizeof (intel_02_known) / sizeof (intel_02_known
[0]))

+/* The bsearch is called early during process initialization before TCB has
+   been set up; and if the compiler does not enable __extern_inline it might
call
+   the symbol which might use an invalid thread-pointer.  */
+#define bsearch bsearch_inline
+#include <bits/stdlib-bsearch.h>
+
 static int
 intel_02_known_compare (const void *p1, const void *p2)
 {
@@ -214,8 +220,8 @@ intel_check_word (int name, unsigned int value, bool
*has_level_2,
          struct intel_02_cache_info search;

          search.idx = byte;
-         found = bsearch (&search, intel_02_known, nintel_02_known,
-                          sizeof (intel_02_known[0]), intel_02_known_compare);
+         found = bsearch_inline (&search, intel_02_known, nintel_02_known,
+                                 sizeof (intel_02_known[0]),
intel_02_known_compare);
          if (found != NULL)
            {
              if (found->rel_name == folded_rel_name)

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

[Bug libc/31655] clang can't build glibc with stack protector

[skpgkp1 at gmail dot com]

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

--- Comment #5 from skpgkp1 at gmail dot com ---
(In reply to H.J. Lu from comment #3)
> (In reply to skpgkp1 from comment #2)
> > Created attachment 15472 [details]
> > Fixes early startup crash.
> > 
> > There is difference between gcc and clang compiler as described in following
> > bug report.
> > 
> > https://bugs.llvm.org/show_bug.cgi?id=33926
> > 
> > If glibc build with option -Wno-error=ignored-attributes, it fixes the early
> > startup crash.
> 
> Does it work without -Wno-error=ignored-attributes?

Without -Wno-error=ignored-attributes glibc build will fail.

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

[Bug libc/31655] clang can't build glibc with stack protector

[adhemerval.zanella at linaro dot org]

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

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I installed a fix for this issue on my azanella/clang, could you check if this
fix the issue on intel chips?

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

[Bug libc/31655] clang can't build glibc with stack protector

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Adhemerval Zanella from comment #4)
> I think we make explicit the constraints in the code, where we can't call
> external symbols in static build.  Something like:
> 
> diff --git a/sysdeps/x86/dl-cacheinfo.h b/sysdeps/x86/dl-cacheinfo.h
> index 5a98f70364..1943dc7db6 100644
> --- a/sysdeps/x86/dl-cacheinfo.h
> +++ b/sysdeps/x86/dl-cacheinfo.h
> @@ -98,6 +98,12 @@ static const struct intel_02_cache_info
> 
>  #define nintel_02_known (sizeof (intel_02_known) / sizeof (intel_02_known
> [0]))
> 
> +/* The bsearch is called early during process initialization before TCB has
> +   been set up; and if the compiler does not enable __extern_inline it
> might call
> +   the symbol which might use an invalid thread-pointer.  */
> +#define bsearch bsearch_inline
> +#include <bits/stdlib-bsearch.h>
> +
>  static int
>  intel_02_known_compare (const void *p1, const void *p2)
>  {

This alone should be sufficient.

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