https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #58 from Ard Biesheuvel ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680098.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #53 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #51)
> Michael, can you give your ack/nack for Ard's proposal in comment #24 (the
> second variant, I guess keying off -m[no-]direct-extern-access doesn't make
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #50 from Ard Biesheuvel ---
(In reply to Ard Biesheuvel from comment #48)
...
> We don't want to be forced to disable the stack protector,
>
I mean 'disable profiling' - there have been some similar issues with the stack
protector,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #48 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #47)
> (In reply to Ard Biesheuvel from comment #43)
> > Non-PIC might be more efficient, but there are cases where we cannot use it.
> > The early startup code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #45 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #44)
> (In reply to Ard Biesheuvel from comment #43)
> > arch/arm64/Makefile specifies '-shared' for the linker flags, but does not
> > pass -fpic of -fpie to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #43 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #42)
> > In Linux, we don't even bother with PIC codegen, even though we link with
> > -pie.
>
> My git-grep for that is coming up empty, where should I look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #41 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #40)
> > In Linux, we don't even bother with PIC codegen, even though we link with
> > -pie.
>
> Earlier you said that building with -fPIC may be desirable, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #39 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #38)
> (In reply to Ard Biesheuvel from comment #37)
> > Yes, we can drop -mcmodel=kernel, and use -mcmodel=small instead. This is
> > why I'm not keen on relyin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #37 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #36)
> Today, gcc rejects -fpic -mcmodel=kernel on the command line though, and it
> doesn't look like you can drop -mcmodel=kernel, so... was there some plan
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #35 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #34)
> We have -mcmodel=kernel already, which is incompatible with -fpic.
>
> Ard, where is -fpic in the kernel context coming from? Kernel's top-level
> Makefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #32 from Ard Biesheuvel ---
Franz, given that you are building your own compiler, mind checking whether the
below fixes the issue for you?
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23154,6 +23154,8 @@
if (fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #26 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #25)
> (In reply to Ard Biesheuvel from comment #24)
> > - never emit 'call mcount'
> > - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> > - emit 'call mcount@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #28 from Ard Biesheuvel ---
(In reply to Franz Sirl from comment #27)
> Maybe silly question, but since the changelog is only talking about
> __fentry__, why couldn't you make the decision based on flag_fentry?
Sadly, I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #24 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #23)
> That's probably just copying existing behavior from 32-bit x86.
>
> Can we preserve previous behavior that under -fpic -mno-direct-extern-access
> mcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #20 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #19)
> The question is why prior to your patch GCC emitted mcount@GOT (i.e.
> avoiding the PLT trampoline for mcount on purpose), going all the way back
> to gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #22 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #21)
> GOT indirection for mcount has been there from the very beginning:
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.
> h?id=c98f874233428d7e6ba83d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #18 from Ard Biesheuvel ---
(In reply to Michael Matz from comment #17)
> (In reply to Ard Biesheuvel from comment #16)
> > OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be
> > removed, and instead, a 'call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #16 from Ard Biesheuvel ---
OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be
removed, and instead, a 'call mcount@PLT' should be emitted.
I suppose this should check for -fno-plt as well, and revert to 'ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #5 from Ard Biesheuvel ---
(In reply to Franz Sirl from comment #4)
> > Note that the GCC man page is pretty clear about this:
> >
> > -mdirect-extern-access
> > -mno-direct-extern-access
> >
> > Do not use or use GOT to access ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #2 from Ard Biesheuvel ---
Note that the GCC man page is pretty clear about this:
-mdirect-extern-access
-mno-direct-extern-access
Do not use or use GOT to access external symbols. The default is
-mno-direct-extern-access: GOT is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #1 from Ard Biesheuvel ---
I don't think -mdirect-extern-access should be used when creating shared
libraries, is there any reason in particular this is being used?
However, given that this is a function call, I'd expect the direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #5 from Ard Biesheuvel ---
Actually, I can reproduce the same behavior without the TLS register, where the
result of a MOVW/MOVT immediate assignment is also spilled to the stack.
int ll[2];
int foo(int);
int bar(void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
--- Comment #3 from Ard Biesheuvel ---
(In reply to Andrew Pinski from comment #1)
> I don't think it is a security risk really because all spills then can be
> considered security risks.
I would argue that there is no consensus on that. In fac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102926
Bug ID: 102926
Summary: TLS register value is spilled to the stack instead of
reloaded from the system register
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102914
Bug ID: 102914
Summary: spurious warnings are emitted on ARM about
non-delegitimized UNSPEC UNSPEC_TLS
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352
Ard Biesheuvel changed:
What|Removed |Added
CC||ardb at kernel dot org
--- Comment #1
26 matches
Mail list logo
