[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #12 from H.J. Lu  ---
(In reply to [email protected] from comment #11)
> >> I don't think -mstack-protector-guard=global matters.  The same test
> >> should fail to link without -mstack-protector-guard=global on Solaris.
> >
> > One way to fix it may be to use
> >
> > #define LINK_SSP_SPEC "--push-state --as-needed -lssp_nonshared -lssp
> > --pop-state"
> >
> > for Solaris.
> 
> This is *not* Solaris-specific, but affects all targets with
> TARGET_LIBC_PROVIDES_SSP undefined.  So this *should* happen in the
> gcc.cc version of LINK_SSP_SPEC.  Besides all of
> --push-state/--pop-state, and --as-needed are GNU ld-specific, so this
> cannot work in general.  And why should this case be special if the
> -fstack-protector* options *do* already trigger linking with
> -lssp_nonshared?

__attribute__ ((optimize ("stack-protector-all"))) triggers libssp requirement.
But GCC driver doesn't know about attribute.  That is why systems which don't
have libc with ssp support don't support __attribute__ ((optimize
("stack-protector-all"))).  "--push-state --as-needed -lssp_nonshared -lssp
--pop-state" is one way
to work around it.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> I don't think -mstack-protector-guard=global matters.  The same test
>> should fail to link without -mstack-protector-guard=global on Solaris.
>
> One way to fix it may be to use
>
> #define LINK_SSP_SPEC "--push-state --as-needed -lssp_nonshared -lssp
> --pop-state"
>
> for Solaris.

This is *not* Solaris-specific, but affects all targets with
TARGET_LIBC_PROVIDES_SSP undefined.  So this *should* happen in the
gcc.cc version of LINK_SSP_SPEC.  Besides all of
--push-state/--pop-state, and --as-needed are GNU ld-specific, so this
cannot work in general.  And why should this case be special if the
-fstack-protector* options *do* already trigger linking with
-lssp_nonshared?

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> As I said, it seems that the test needs to be linked with -lssp_nonshared
>> -lssp
>> on targets withoutTARGET_LIBC_PROVIDES_SSP.  However, the LINK_SSP_SPEC in
>> gcc.cc doesn't do that for -mstack-protector-guard=global.  Looks like a bug
>> in my book.
>
> I don't think -mstack-protector-guard=global matters.  The same test
> should fail to link without -mstack-protector-guard=global on Solaris.

It does, but there's no other option that could trigger the
LINK_SSP_SPEC to link with -lssp_nonshared.  So how else do you suggest
this to happen when it's obivously necessary for the test to link?

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #9 from H.J. Lu  ---
(In reply to H.J. Lu from comment #8)

> > As I said, it seems that the test needs to be linked with -lssp_nonshared
> > -lssp
> > on targets withoutTARGET_LIBC_PROVIDES_SSP.  However, the LINK_SSP_SPEC in
> > gcc.cc doesn't do that for -mstack-protector-guard=global.  Looks like a bug
> > in my book.
> > 
> 
> I don't think -mstack-protector-guard=global matters.  The same test
> should fail to link without -mstack-protector-guard=global on Solaris.

One way to fix it may be to use

#define LINK_SSP_SPEC "--push-state --as-needed -lssp_nonshared -lssp
--pop-state"

for Solaris.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #8 from H.J. Lu  ---
(In reply to Rainer Orth from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Rainer Orth from comment #5)
> > > On Linux/i686 the __stack_chk_fail_local reference is resolved from
> > > 
> > > /usr/lib32/libc_nonshared.a
> > > 
> > > which gets dragged in by /lib/../lib32/libc.so:
> > > 
> > > /* GNU ld script
> > >Use the shared library, but some functions are only in
> > >the static library, so try that secondarily.  */
> > > OUTPUT_FORMAT(elf32-i386)
> > > GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
> > > /lib/ld-linux.
> > > so.2 ) )
> > > 
> > > Solaris has no such think, so would need to link with -lssp_nonshared
> > > instead!?
> > 
> > You need to find a way to support __attribute__ ((optimize
> > ("stack-protector-all")))
> > on Solaris or disallow it on Solaris.
> 
> I don't think so: if, just for the sake of argument, if you replace the
> libc.so
> linker script on Linux by a symlink to libc.so.6, the test FAILs exactly the
> same as on Solaris, assuming Linux/x86 *does* support that attribute.
> 
> As I said, it seems that the test needs to be linked with -lssp_nonshared
> -lssp
> on targets withoutTARGET_LIBC_PROVIDES_SSP.  However, the LINK_SSP_SPEC in
> gcc.cc doesn't do that for -mstack-protector-guard=global.  Looks like a bug
> in my book.
> 

I don't think -mstack-protector-guard=global matters.  The same test
should fail to link without -mstack-protector-guard=global on Solaris.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-08 Thread ro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

Rainer Orth  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Target|x86 |i386-pc-solaris2.11,
   ||x86_64-pc-solaris2.11
   Target Milestone|--- |17.0

--- Comment #7 from Rainer Orth  ---
(In reply to H.J. Lu from comment #6)
> (In reply to Rainer Orth from comment #5)
> > On Linux/i686 the __stack_chk_fail_local reference is resolved from
> > 
> > /usr/lib32/libc_nonshared.a
> > 
> > which gets dragged in by /lib/../lib32/libc.so:
> > 
> > /* GNU ld script
> >Use the shared library, but some functions are only in
> >the static library, so try that secondarily.  */
> > OUTPUT_FORMAT(elf32-i386)
> > GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
> > /lib/ld-linux.
> > so.2 ) )
> > 
> > Solaris has no such think, so would need to link with -lssp_nonshared
> > instead!?
> 
> You need to find a way to support __attribute__ ((optimize
> ("stack-protector-all")))
> on Solaris or disallow it on Solaris.

I don't think so: if, just for the sake of argument, if you replace the libc.so
linker script on Linux by a symlink to libc.so.6, the test FAILs exactly the
same as on Solaris, assuming Linux/x86 *does* support that attribute.

As I said, it seems that the test needs to be linked with -lssp_nonshared -lssp
on targets withoutTARGET_LIBC_PROVIDES_SSP.  However, the LINK_SSP_SPEC in
gcc.cc doesn't do that for -mstack-protector-guard=global.  Looks like a bug
in my book.

It would help tremendously if you'd actually read what I wrote rather than
summarily claim that any non-Linux target is broken/buggy...

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #6 from H.J. Lu  ---
(In reply to Rainer Orth from comment #5)
> On Linux/i686 the __stack_chk_fail_local reference is resolved from
> 
> /usr/lib32/libc_nonshared.a
> 
> which gets dragged in by /lib/../lib32/libc.so:
> 
> /* GNU ld script
>Use the shared library, but some functions are only in
>the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf32-i386)
> GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
> /lib/ld-linux.
> so.2 ) )
> 
> Solaris has no such think, so would need to link with -lssp_nonshared
> instead!?

You need to find a way to support __attribute__ ((optimize
("stack-protector-all")))
on Solaris or disallow it on Solaris.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread ro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #5 from Rainer Orth  ---
On Linux/i686 the __stack_chk_fail_local reference is resolved from

/usr/lib32/libc_nonshared.a

which gets dragged in by /lib/../lib32/libc.so:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
/lib/ld-linux.
so.2 ) )

Solaris has no such think, so would need to link with -lssp_nonshared instead!?

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> Does Solaris libc support stack protector?  If yes, __stack_chk_fail_local is

No, as you could easily find out e.g. on cfarm215 if you just once
tested your patches that are bound to affect non-Linux/x86 targets on at
least one of those systems.

> missing in Solaris libc.  If no, Solaris should use libssp which provides
> stack protector features, including __stack_chk_fail_local, when stack
> protector
> is enabled.

It does use libssp in general via gcc.cc (LINK_SSP_SPEC).  However, this
test doesn't use any of the -fstack-protector* options that are handled
there, but -mstack-protector-guard=global which isn't.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #3 from H.J. Lu  ---
(In reply to [email protected] from comment #2)
> > On Linux/x86, it's provided by libc.so.6 instead:
> >
> > readelf -sW /lib32/libc.so.6|grep __stack_chk
> >562: 0013541025 FUNCGLOBAL DEFAULT   14 
> > __stack_chk_fail@@GLIBC_2.4
> >
> > Seems like a bug in the map file to me.
> 
> Scratch that of course ;-(

Does Solaris libc support stack protector?  If yes, __stack_chk_fail_local is
missing in Solaris libc.  If no, Solaris should use libssp which provides
stack protector features, including __stack_chk_fail_local, when stack
protector
is enabled.

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> On Linux/x86, it's provided by libc.so.6 instead:
>
> readelf -sW /lib32/libc.so.6|grep __stack_chk
>562: 0013541025 FUNCGLOBAL DEFAULT   14 __stack_chk_fail@@GLIBC_2.4
>
> Seems like a bug in the map file to me.

Scratch that of course ;-(

[Bug target/125205] FAIL: gcc.target/i386/ssp-global-hidden-3.c (test for excess errors)

2026-05-06 Thread ro at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125205

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
*Please* Cc me in PRs you file for Solaris issues.

(In reply to H.J. Lu from comment #0)

> Since ix86_stack_protect_fail returns default_external_stack_protect_fail for
> 64-bit and default_hidden_stack_protect_fail for 32-bit which references
> __stack_chk_fail_local.  But __stack_chk_fail_local isn't provided on
> Solaris.

It is present all right:

for x in .libs/*.{a,so}; do echo $x; readelf -sW $x|grep
__stack_chk_fail_local; done
.libs/libssp_nonshared.a
10: 28 FUNCGLOBAL HIDDEN 2 __stack_chk_fail_local
.libs/libssp.a
29: 013011 FUNCGLOBAL HIDDEN 1 __stack_chk_fail_local
.libs/libssp.so
48: 166028 FUNCLOCAL  HIDDEN17 __stack_chk_fail_local

The only difference to Linux is that it's local/hidden in libssp.so since
it's not exported in ssp.map.

On Linux/x86, it's provided by libc.so.6 instead:

readelf -sW /lib32/libc.so.6|grep __stack_chk
   562: 0013541025 FUNCGLOBAL DEFAULT   14 __stack_chk_fail@@GLIBC_2.4

Seems like a bug in the map file to me.