Bug 29838

Summary: -fstack-protector shouldn't use TLS in freestanding mode
Product: gcc Reporter: Samuel Thibault <samuel.thibault>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: UNCONFIRMED ---    
Severity: normal CC: egall, gcc-bugs, jakub, roland, tschwinge
Priority: P3    
Version: unknown   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:
Attachments: braindead patch

Description Samuel Thibault 2006-11-15 01:14:29 UTC

On some architectures, when given -fstack-protector (which is the default on ubuntu), gcc generates a TLS reference for the stack guard. For instance, on linux x86 with a fairly recent version of glibc:

echo 'void f (void) { volatile char a[8]; a[3]; }' | gcc -S -x c -O2 -fstack-protector - -o -

generates a %gs:0x14 reference.

In freestanding mode, this poses problem because the target (typically an OS kernel) does not necessarily have TLS.  In such case, gcc should default back to referencing __stack_chk_guard.

Comment 1 Samuel Thibault 2006-11-15 01:16:54 UTC
Created attachment 12622 [details]
braindead patch

Just a small braindead patch, not tested at all, just adds testing flag_hosted.
Comment 2 Andrew Pinski 2006-11-15 02:50:15 UTC
Seems to me, you should not be using a target that defines TARGET_THREAD_SSP_OFFSET for -ffreestanding mode.  Also IIRC the x86_64 Linux has a different TLS base register which fixes this issue there.
Comment 3 Samuel Thibault 2006-11-15 09:33:13 UTC
Mmm, if I have to use another target for avoiding my default target's specific stuff, what is the use of -ffreestanding?

Does that mean that we will have to add a linux-kernel target (as opposed to linux-user target) and build a cross-compiler before building a linux kernel? (replace "linux" with whatever kernel you want).

And x86_64 Linux just poses the same problem: it emits %fs:0x28 instead of %gs:0x14, but it's just the same issue.
Comment 4 Thomas Schwinge 2006-11-15 10:11:16 UTC
Cced to Jakub Jelinek, who originally implemented this functionality.  Could you please comment on this issue?
Comment 6 Samuel Thibault 2006-11-15 10:30:23 UTC
So you are saying that gcc now imposes (whatever the kernel) kernel-land and user-land to use the same TLS scheme, and now requires people to build a cross-compiler before building a kernel from another kernel's userland?  I thought -ffreestanding was precisely meant to escape such considerations...
Comment 7 Jakub Jelinek 2006-11-15 10:37:54 UTC
Using %fs:0x28/%gs:0x28 on x86_64-linux resp. %gs:0x14 on i?86-linux is part
of the ABI.  -ffreestanding is not supposed to change the ABI, so if you
don't want to use this ABI, just use a different target (x86_64-elf etc., or don't use -fstack-protector (nobody forces you to use that).
Comment 8 Jakub Jelinek 2006-11-15 10:41:23 UTC
If you use __thread in -ffreestanding it is the same, you don't get emulated
TLS either.
Comment 9 Samuel Thibault 2006-11-15 11:01:42 UTC
About not using -fstack-protector, the problem is that it is the default on ubuntu for instance.  That would mean we have to explicitely use -fno-stack-protector, but only for recent versions of gcc, so we'll have to detect that, etc... Not counting all such new options that may arise which we'd have to disable...

Please answer this, at least by just yes/no: you're saying that -ffreestanding doesn't mean "an OS kernel" (as manual says), but "the kernel of the target", so that people working on other kernels will have to first build a cross-compiler? (the bug is a documentation bug then)
Comment 10 Thomas Schwinge 2006-12-15 19:30:21 UTC
Roland McGrath proposed the following: ``I think it really ought to be controlled by a -mno-stack-protector-tls or suchlike, for complete flexibility.  Obviously it should default to disabled for -ffreestanding.''
Comment 11 Eric Gallager 2015-01-08 17:11:58 UTC
If changing the code generation or adding a new flag to control this is too difficult, how about just adding this to the list of things that "-Wstack-protector" warns about in the meantime?
Comment 12 Thomas Schwinge 2017-01-18 07:41:08 UTC
See also PR78875.