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
> > > > > > explicitly load the address of __fentry__ from the GOT, which
> > > > > > amou
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 profili
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 trying to commit aarch64 scs code to the gcc and there is an issue
> >> that 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
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
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 support for accessing the stack canary value via the TLS re
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 address space can use
> > distinct can
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 in
> SMP mode, whe
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
On Tue, 9 Nov 2021 at 21:45, Qing Zhao wrote:
>
> Hi, Ard,
>
> Sorry for the late reply (since I don’t have the right to approve a patch, I
> has been waiting for any arm port maintainer to review this patch).
> The following is the arm port maintainer information I got from MAINTAINERS
> file (
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 terminates. This means that u
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
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
> SMP mode, where processes
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
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 terminates. This means that u
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
SMP mode, where processes entering the kernel are essentially threads
running the same p
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 terminates. This means that using a global variable for the stack
protector canary value is p
28 matches
Mail list logo
