https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #20 from Andrew Pinski ---
*** Bug 70148 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #19 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:4ad200addc3eaf55fba6cc91db3d3b66eabaf3d0
commit r13-2043-g4ad200addc3eaf55fba6cc91db3d3b66eabaf3d0
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #18 from Alexandre Oliva ---
on x86_64 with -fPIC or -fpic, my_guard's address is indeed loaded from the GOT
with @GOTPCREL indeed
on x86_64 with -fPIE or -fpie, however, it is used just as expected by the
testcase. which should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #17 from H.J. Lu ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
>
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
>
When PIC/P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #16 from Uroš Bizjak ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
>
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
>
> After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #14 from Aldy Hernandez ---
Author: aldyh
Date: Wed Sep 13 16:51:37 2017
New Revision: 252397
URL: https://gcc.gnu.org/viewcvs?rev=252397&root=gcc&view=rev
Log:
PR target/81708
* config/i386/i386.opt (mstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #13 from Aldy Hernandez ---
Author: aldyh
Date: Wed Sep 13 16:41:28 2017
New Revision: 252350
URL: https://gcc.gnu.org/viewcvs?rev=252350&root=gcc&view=rev
Log:
PR target/81708
* config/i386/i386.opt (mstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 10 20:59:10 2017
New Revision: 251040
URL: https://gcc.gnu.org/viewcvs?rev=251040&root=gcc&view=rev
Log:
PR target/81708
* config/i386/i386.opt (mstack-pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #11 from Uroš Bizjak ---
(In reply to H. Peter Anvin from comment #8)
> How about simply letting the user enter an assembly expression of neither of
> the standard ABI options are suitable? Also, shouldn't the user space
> default on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #10 from Uroš Bizjak ---
Created attachment 41955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41955&action=edit
patch that introduces mstack-protector-guard-symbol=
This patch can be used to override TLS offset with a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #9 from H. Peter Anvin ---
In some applications it might even be appropriate to use the RDPID instruction
and store the canary in the IA32_TSC_AUX MSR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #8 from H. Peter Anvin ---
How about simply letting the user enter an assembly expression of neither of
the standard ABI options are suitable? Also, shouldn't the user space default
on 64 bits be an offset into the TLS using %fs, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #7 from Andy Lutomirski ---
Hmm. This is a big improvement, but it's still going to be awkward to use --
if we want to use a normal Linux percpu variable, we're stuck putting it in a
fixed location that's known at compile time as opp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Aug 8 16:48:46 2017
New Revision: 250965
URL: https://gcc.gnu.org/viewcvs?rev=250965&root=gcc&view=rev
Log:
PR target/81708
* config/i386/i386.opt (mstack-pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 41949 [details]
> Patch that introduces mstack-protector-guard-offset= and
> mstack-protector-guard-reg=
e.g.:
-mstack-protector-guard-reg=%fs -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #3 from Uroš Bizjak ---
Created attachment 41949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41949&action=edit
Patch that introduces mstack-protector-guard-offset= and
mstack-protector-guard-reg=
Prototype patch that introdu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #2 from Andy Lutomirski ---
(In reply to H. Peter Anvin from comment #1)
> Well, you can choose between "__stack_chk_guard(%rip)" and "%gs:40"... :)
Wow, I guess I didn't even consider the former. That would be option 5:
symbol(%rip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #1 fro
21 matches
Mail list logo
