https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #16 from Andy Lutomirski ---
(In reply to Andrew Pinski from comment #13)
> Patient: Doctor it hurts when I do this.
> Doctor: then don't do that and if you read the instructions I gave you I
> told you I would hurt this way.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997
--- Comment #4 from Andy Lutomirski ---
I should add: on brief inspection, that patch looks like an ABI break for
-fcf-protection=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997
--- Comment #3 from Andy Lutomirski ---
What is -fcf-protection=stack actually supposed to do as compared to
-fcf-protection=none? Is it valid to run code compiled with
-fcf-protection=none with SHSTK enabled? If so, then I wonder why
-fcf-prot
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877
Andy Lutomirski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234
--- Comment #2 from Andy Lutomirski ---
*** Bug 57998 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998
Andy Lutomirski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
Created attachment 46672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46672&action=edit
Example
For a non-empty vector v, calling v.operator[](v.size()) fir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #13 from Andy Lutomirski ---
I find this whole discussion very confusing. The problem has nothing to do
with relocations AFAICT. The problem is that gcc is (as requested) generating
retpolines, and it's set up to do it by calling __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
Andy Lutomirski changed:
What|Removed |Added
CC||luto at kernel dot org
--- Comment #9
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
I compiled this:
void func()
{
int var __attribute__((aligned(32)));
asm volatile ("" :: "m" (var));
}
using gcc (GCC) 7.1.1 20170622 (Red
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=81490
--- Comment #28 from Andy Lutomirski ---
hjl, I don't understand what problem you're trying to solve here. Your patch
makes it relatively straightforward to access global variables using __seg_gs
if the environment sets up the %gs base exactly t
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=81490
--- Comment #21 from Andy Lutomirski ---
Re: the stack canary, I filed bug 81708. It seems to me that __seg_gs is
analogous and users should be able to directly specify the addressing mode.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
There are four credible ways to find the stack canary:
1. %fs:symbol
2. %fs:symbol(%rip) [with a PCREL relocation]
3. %gs:symbol
4. %gs:symbol(%rip)
(Obviously the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #20 from Andy Lutomirski ---
We have issues putting modules more than 2G from the main kernel no matter
what, but I don't see what this has to do with %gs addressing.
I still think that GCC should let us directly control the addressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #14 from Andy Lutomirski ---
(In reply to H. Peter Anvin from comment #13)
> On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com
> wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
> >OTOH, we can avoid RIP relative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
Andy Lutomirski changed:
What|Removed |Added
CC||luto at kernel dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68491
Andy Lutomirski changed:
What|Removed |Added
CC||luto at kernel dot org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66795
--- Comment #2 from Andy Lutomirski ---
(In reply to Andrew Pinski from comment #1)
> The code below is invalid as __builtin_frame_address is only for reading
> from the current frame.
If this code is invalid, then what exactly is valid code tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
--- Comment #6 from Andy Lutomirski ---
The PLT case could be reduced significantly by -fno-plt, but the TLS issue is
just sad. I don't suppose it could be fixed with just toolchain changes while
retaining compatibility with existing libc versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
--- Comment #3 from Andy Lutomirski ---
I think a similar optimization could be applied to default-visibility
references as well. For example, gcc can generate things like this:
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFF
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
The 32-bit x86 Linux kernel jumps through ridiculous hoops to but the SSP
canary where GCC expects it. (If I had been paying attention when that
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
If I compile:
extern char foo[] __attribute__((visibility("hidden")));
char *get_foo(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Andy Lutomirski changed:
What|Removed |Added
Severity|enhancement |major
--- Comment #9 from Andy Lutomir
26 matches
Mail list logo
