public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/31655] New: clang can't build glibc with stack protector
@ 2024-04-18 15:00 hjl.tools at gmail dot com
2024-04-18 15:08 ` [Bug libc/31655] " adhemerval.zanella at linaro dot org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: hjl.tools at gmail dot com @ 2024-04-18 15:00 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
@ 2024-04-18 15:08 ` adhemerval.zanella at linaro dot org
2024-04-18 17:43 ` skpgkp1 at gmail dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2024-04-18 15:08 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
2024-04-18 15:08 ` [Bug libc/31655] " adhemerval.zanella at linaro dot org
@ 2024-04-18 17:43 ` skpgkp1 at gmail dot com
2024-04-18 17:45 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: skpgkp1 at gmail dot com @ 2024-04-18 17:43 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
2024-04-18 15:08 ` [Bug libc/31655] " adhemerval.zanella at linaro dot org
2024-04-18 17:43 ` skpgkp1 at gmail dot com
@ 2024-04-18 17:45 ` hjl.tools at gmail dot com
2024-04-18 18:10 ` adhemerval.zanella at linaro dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: hjl.tools at gmail dot com @ 2024-04-18 17:45 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
` (2 preceding siblings ...)
2024-04-18 17:45 ` hjl.tools at gmail dot com
@ 2024-04-18 18:10 ` adhemerval.zanella at linaro dot org
2024-04-18 18:13 ` skpgkp1 at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2024-04-18 18:10 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
` (3 preceding siblings ...)
2024-04-18 18:10 ` adhemerval.zanella at linaro dot org
@ 2024-04-18 18:13 ` skpgkp1 at gmail dot com
2024-04-18 19:31 ` adhemerval.zanella at linaro dot org
2024-04-18 19:37 ` hjl.tools at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: skpgkp1 at gmail dot com @ 2024-04-18 18:13 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
` (4 preceding siblings ...)
2024-04-18 18:13 ` skpgkp1 at gmail dot com
@ 2024-04-18 19:31 ` adhemerval.zanella at linaro dot org
2024-04-18 19:37 ` hjl.tools at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2024-04-18 19:31 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31655] clang can't build glibc with stack protector
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
` (5 preceding siblings ...)
2024-04-18 19:31 ` adhemerval.zanella at linaro dot org
@ 2024-04-18 19:37 ` hjl.tools at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: hjl.tools at gmail dot com @ 2024-04-18 19:37 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-04-18 19:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-18 15:00 [Bug libc/31655] New: clang can't build glibc with stack protector hjl.tools at gmail dot com
2024-04-18 15:08 ` [Bug libc/31655] " adhemerval.zanella at linaro dot org
2024-04-18 17:43 ` skpgkp1 at gmail dot com
2024-04-18 17:45 ` hjl.tools at gmail dot com
2024-04-18 18:10 ` adhemerval.zanella at linaro dot org
2024-04-18 18:13 ` skpgkp1 at gmail dot com
2024-04-18 19:31 ` adhemerval.zanella at linaro dot org
2024-04-18 19:37 ` hjl.tools at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).