On Tue, 15 Apr 2025 at 09:48, Uros Bizjak wrote:
>
> On Thu, Apr 10, 2025 at 2:27 PM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the
From: Ard Biesheuvel
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
The
On Wed, 9 Apr 2025 at 09:12, Uros Bizjak wrote:
>
> On Tue, Apr 8, 2025 at 6:59 PM Ard Biesheuvel wrote:
> >
> > On Tue, 8 Apr 2025 at 18:44, H.J. Lu wrote:
> > >
> > > On Tue, Apr 8, 2025 at 9:39 AM Ard Biesheuvel wrote:
> > > >
>
On Wed, 9 Apr 2025 at 16:46, H.J. Lu wrote:
>
> On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic tha
From: Ard Biesheuvel
-mnop-mcount can be trivially enabled for -fPIC codegen as long as PLTs
are being used, given that the instruction encodings are identical, only
the target may resolve differently depending on how the linker decides
to incorporate the object file.
So relax the option check
From: Ard Biesheuvel
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
The
On Tue, 8 Apr 2025 at 15:33, H.J. Lu wrote:
>
> On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic tha
From: Ard Biesheuvel
On 64-bit, -mnop-mcount can be trivially enabled for -fPIC codegen as
long as PLTs are being used, given that the instruction encodings are
identical, only the target may resolve differently depending on how the
linker decides to incorporate the object file.
So relax the
From: Ard Biesheuvel
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
The
On Tue, 8 Apr 2025 at 18:44, H.J. Lu wrote:
>
> On Tue, Apr 8, 2025 at 9:39 AM Ard Biesheuvel wrote:
> >
> > On Tue, 8 Apr 2025 at 15:33, H.J. Lu wrote:
> > >
> > > On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel wrote:
> > > >
> > > &
From: Ard Biesheuvel
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
The
On Sun, 6 Apr 2025 at 12:58, Alexander Monakov wrote:
>
> On Fri, 4 Apr 2025, Ard Biesheuvel wrote:
>
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that e
From: Ard Biesheuvel
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
The
On Fri, 12 May 2023 at 19:05, Uros Bizjak wrote:
>
> On Fri, May 12, 2023 at 4:07 PM Ard Biesheuvel wrote:
>
> > > > > > Note that the GOT reference in question is in fact a data
> > > > > > reference: we
> > > > > >
On Thu, 11 May 2023 at 08:08, Uros Bizjak wrote:
>
> On Thu, May 11, 2023 at 12:04 AM H.J. Lu wrote:
> >
> > On Wed, May 10, 2023 at 2:17 AM Uros Bizjak wrote:
> > >
> > > On Tue, May 9, 2023 at 10:58 AM Ard Biesheuvel wrote:
> > > >
>
The small and medium PIC code models generate profiling calls that
always load the address of __fentry__() via the GOT, even if
-mdirect-extern-access is in effect.
This deviates from the behavior with respect to other external
references, and results in a longer opcode that relies on linker
relax
On Wed, 26 Jan 2022 at 11:40, Dan Li wrote:
>
> Thanks, Ard,
>
> On 1/26/22 00:10, Ard Biesheuvel wrote:
> > On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
> >>
> >> Hi, all,
> >>
> >> Sorry for bothering.
> >>
> >> I'm
On Wed, 26 Jan 2022 at 08:53, Dan Li wrote:
>
> Hi, all,
>
> Sorry for bothering.
>
> I'm trying to commit aarch64 scs code to the gcc and there is an issue
> that I'm not sure about, could someone give me some suggestions?
> (To avoid noise, I did't cc PING^3 [1] to the kernel mail list :) )
>
>
On Fri, 21 Jan 2022 at 11:47, Kyrylo Tkachov wrote:
>
> > -Original Message-
> > From: Gcc-patches > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Ard
> > Biesheuvel via Gcc-patches
> > Sent: Wednesday, January 19, 2022 5:44 PM
> > To:
On Wed, 19 Jan 2022 at 18:02, Ard Biesheuvel wrote:
>
> On Wed, 19 Jan 2022 at 17:54, Kyrylo Tkachov wrote:
> >
> > Hi Ard,
> >
> > > -Original Message-
> > > From: Gcc-patches > > bounces+kyrylo.tkachov=arm....@gcc.gnu.org> On Behalf
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2022-01-19 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New
Cc: adhemerval.zane...@linaro.org
Cc: Qing Zhao
Cc: Richard Sandiford
Cc: Kyrylo Tkachov
Cc: Richard Earnshaw
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add support for TLS register based stack protector canary access
gcc/config/arm/arm-opts.h| 6 ++
gcc/config/
On Wed, 19 Jan 2022 at 17:54, Kyrylo Tkachov wrote:
>
> Hi Ard,
>
> > -Original Message-
> > From: Gcc-patches > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Ard
> > Biesheuvel via Gcc-patches
> > Sent: Monday, November 15, 2021 6:04 PM
(+ Richard Earnshaw)
On Wed, 12 Jan 2022 at 19:29, Ard Biesheuvel wrote:
>
> On Wed, 17 Nov 2021 at 18:12, Ard Biesheuvel wrote:
> >
> > (+ Ramana)
> >
>
> Ping?
>
> > On Mon, 15 Nov 2021 at 19:04, Ard Biesheuvel wrote:
> > >
> > > Add
On Wed, 17 Nov 2021 at 18:12, Ard Biesheuvel wrote:
>
> (+ Ramana)
>
Ping?
> On Mon, 15 Nov 2021 at 19:04, Ard Biesheuvel wrote:
> >
> > Add support for accessing the stack canary value via the TLS register,
> > so that multiple threads running in the same addr
On Wed, 17 Nov 2021 at 10:09, Ramana Radhakrishnan
wrote:
>
> Thanks Ard and Qing.
>
>
>
> I have been busy with other things in the last few weeks and I don’t work on
> GCC as part of my day job : however I’ll try to find some time to review this
> patch set in the coming days.
>
>
Hello Raman
(+ Ramana)
On Mon, 15 Nov 2021 at 19:04, Ard Biesheuvel wrote:
>
> Add support for accessing the stack canary value via the TLS register,
> so that multiple threads running in the same address space can use
> distinct canary values. This is intended for the Linux kernel running i
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2021-11-15 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New
template for stack_protect_test_tls so it correctly conveys
the fact that it sets the Z flag
Cc: Keith Packard
Cc: thomas.preudho...@celest.fr
Cc: adhemerval.zane...@linaro.org
Cc: Qing Zhao
Cc: Richard Sandiford
Cc: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add
which is kind of
odd so we did not want to hard code that.
> 3. For the functionality you added, I didn’t see any testing cases added, I
> think testing cases are needed.
>
Yes, I am aware of that. I'm just not sure I know how to proceed here:
any pointers?
> More comments are emb
On Thu, 28 Oct 2021 at 13:27, Ard Biesheuvel wrote:
>
> Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352
>
> In the Linux kernel, user processes calling into the kernel are
> essentially threads running in the same address space, of a program that
> never terminate
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2021-10-28 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New
Comments/suggestions welcome.
Cc: Keith Packard
Cc: thomas.preudho...@celest.fr
Cc: adhemerval.zane...@linaro.org
Cc: Qing Zhao
Cc: Richard Sandiford
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add support for TLS register based stack protector canary access
gcc/config/arm/arm-opts.h
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2021-10-21 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New
/suggestions welcome.
Cc: Keith Packard
Cc: thomas.preudho...@celest.fr
Cc: adhemerval.zane...@linaro.org
Cc: Qing Zhao
Cc: Richard Sandiford
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add support for TLS register based stack protector canary access
gcc/config/arm/arm-opts.h
On Thu, 21 Oct 2021 at 18:51, Ard Biesheuvel wrote:
>
> Add support for accessing the stack canary value via the TLS register,
> so that multiple threads running in the same address space can use
> distinct canary values. This is intended for the Linux kernel running in
>
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2021-10-21 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New
Cc: Richard Sandiford
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add support for TLS register based stack protector canary access
gcc/config/arm/arm-opts.h | 6 ++
gcc/config/arm/arm-protos.h | 2 +
gcc/config/arm/arm.c| 52
gcc/config/arm/arm.md
On Thu, 21 Oct 2021 at 12:23, Ard Biesheuvel wrote:
>
> Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352
>
> In the Linux kernel, user processes calling into the kernel are
> essentially threads running in the same address space, of a program that
> never terminate
switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.
2021-10-20 Ard Biesheuvel
* config/arm/arm-opts.h (enum stack_protector_guard): New
* config/arm/arm.c (arm_option_override_internal): Handle
and put
fr
Cc: adhemerval.zane...@linaro.org
Cc: Qing Zhao
Cc: Richard Sandiford
Cc: gcc-patches@gcc.gnu.org
Ard Biesheuvel (1):
[ARM] Add support for TLS register based stack protector canary access
gcc/config/arm/arm-opts.h | 6 +++
gcc/config/arm/arm.c | 39 +
gcc/config/arm/a
On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
> command line option
42 matches
Mail list logo
