On 10/20/20 2:19 PM, Richard Biener wrote:
So can we use the same identifier as clang here as Nick
requests? Thus, OK with re-naming everything alongside
no_stack_protector. It isn't really the opposite of the
stack_protect attribute since that only protects when
-fstack-protector-explicit is e
+ correct kernel mailing list this time.
On Wed, Oct 21, 2020 at 2:33 PM Nick Desaulniers
wrote:
>
> Thanks for the quick feedback!
>
> On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> > wrote:
> > > Tangen
Thanks for the quick feedback!
On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek wrote:
>
> On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
> wrote:
> > Tangentially related question:
> > We're running into a bug related to LTO for the kernel when code
> > compiled with -f
On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches
wrote:
> Tangentially related question:
> We're running into a bug related to LTO for the kernel when code
> compiled with -fno-stack-protector is called from and inlined into
> code that is compiled with -fstack-protector.
On Tue, Oct 20, 2020 at 5:19 AM Richard Biener
wrote:
>
> On Tue, Oct 20, 2020 at 1:24 PM Martin Liška wrote:
> >
> > PING^5
>
> So can we use the same identifier as clang here as Nick
> requests? Thus, OK with re-naming everything alongside
> no_stack_protector. It isn't really the opposite of
On Tue, Oct 20, 2020 at 1:24 PM Martin Liška wrote:
>
> PING^5
So can we use the same identifier as clang here as Nick
requests? Thus, OK with re-naming everything alongside
no_stack_protector. It isn't really the opposite of the
stack_protect attribute since that only protects when
-fstack-pro
PING^5
On 8/17/20 2:35 PM, Martin Liška wrote:
PING^4
On 7/23/20 1:10 PM, Martin Liška wrote:
PING^3
On 6/24/20 11:09 AM, Martin Liška wrote:
PING^2
On 6/10/20 10:12 AM, Martin Liška wrote:
PING^1
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20
On 8/25/20 4:46 PM, Nick Desaulniers wrote:
This would solve a common pattern in the kernel where folks are using
`extern inline` with `gnu_inline` semantics or worse (empty `asm("");`
statements) in certain places where it would be much more preferable
to have this attribute. Thank you very muc
This would solve a common pattern in the kernel where folks are using
`extern inline` with `gnu_inline` semantics or worse (empty `asm("");`
statements) in certain places where it would be much more preferable
to have this attribute. Thank you very much Martin for writing it.
> is direct equivale
PING^4
On 7/23/20 1:10 PM, Martin Liška wrote:
PING^3
On 6/24/20 11:09 AM, Martin Liška wrote:
PING^2
On 6/10/20 10:12 AM, Martin Liška wrote:
PING^1
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 P
PING^3
On 6/24/20 11:09 AM, Martin Liška wrote:
PING^2
On 6/10/20 10:12 AM, Martin Liška wrote:
PING^1
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some som
PING^2
On 6/10/20 10:12 AM, Martin Liška wrote:
PING^1
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some somewhat complex cases the attribute exclusion
mechan
On 6/10/20 2:12 AM, Martin Liška wrote:
PING^1
The exclusion changes are just what I was suggesting, thanks.
Martin
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know the
PING^1
On 5/25/20 3:10 PM, Martin Liška wrote:
On 5/21/20 4:53 PM, Martin Sebor wrote:
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some somewhat complex cases the attribute exclusion
mechanism isn't general enough to handle but this seems
2 +0200
Subject: [PATCH] Implement no_stack_protect attribute.
gcc/ChangeLog:
2020-05-18 Martin Liska
PR c/94722
* cfgexpand.c (stack_protect_decl_phase):
Guard with lookup_attribute("no_stack_protect") at
various places.
(expand_used_vars): Likewise here.
* doc/extend.texi: Do
On Mon, May 25, 2020 at 11:27 AM Martin Liška wrote:
>
> On 5/22/20 12:51 PM, Richard Biener wrote:
> > On Thu, May 21, 2020 at 12:09 PM Martin Liška wrote:
> >>
> >> On 5/18/20 1:49 PM, Richard Biener wrote:
> >>> On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
> >>> wrote:
>
On 5/22/20 12:51 PM, Richard Biener wrote:
On Thu, May 21, 2020 at 12:09 PM Martin Liška wrote:
On 5/18/20 1:49 PM, Richard Biener wrote:
On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
wrote:
On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
The optimize attrib
On Thu, May 21, 2020 at 12:09 PM Martin Liška wrote:
>
> On 5/18/20 1:49 PM, Richard Biener wrote:
> > On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
> > wrote:
> >>
> >> On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> The optimize attribute is used to specify
On 5/21/20 5:28 AM, Martin Liška wrote:
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some somewhat complex cases the attribute exclusion
mechanism isn't general enough to handle but this seems simple enough
that it should work. Unless I'm missing something that makes it not
feasibl
On 5/18/20 10:37 PM, Martin Sebor wrote:
I know there are some somewhat complex cases the attribute exclusion
mechanism isn't general enough to handle but this seems simple enough
that it should work. Unless I'm missing something that makes it not
feasible I would suggest to use it.
Hi Martin.
On 5/18/20 5:56 PM, Florian Weimer via Gcc-patches wrote:
* Michael Matz:
So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
all for some reason, the frame pointer is always missing?
Not for me:
I see. I didn't know that -fno-omit-frame-pointer only applies to
non-lea
On 5/18/20 1:49 PM, Richard Biener wrote:
On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
wrote:
On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
The optimize attribute is used to specify that a function is to be compiled
with different optimization options than sp
On 5/18/20 4:37 AM, Martin Liška wrote:
Hi.
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used wit
On Mai 18 2020, Florian Weimer via Gcc-patches wrote:
> * Michael Matz:
>
>>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
>>> all for some reason, the frame pointer is always missing?
>>
>> Not for me:
>
> I see. I didn't know that -fno-omit-frame-pointer only applie
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> * Michael Matz:
>
> >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
> >> all for some reason, the frame pointer is always missing?
> >
> > Not for me:
>
> I see. I didn't know that -fno-omit-frame-pointer only app
* Michael Matz:
>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at
>> all for some reason, the frame pointer is always missing?
>
> Not for me:
I see. I didn't know that -fno-omit-frame-pointer only applies to
non-leaf functions. For them, the behavior I see matches yo
Hello,
On Mon, 18 May 2020, Florian Weimer wrote:
> >> In glibc, we already have this:
> >>
> >> /* Used to disable stack protection in sensitive places, like ifunc
> >>resolvers and early static TLS init. */
> >> #ifdef HAVE_CC_NO_STACK_PROTECTOR
> >> # define inhibit_stack_protector \
> >
* Michael Matz:
> Hello,
>
> On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
>
>> > The patch adds new no_stack_protect attribute. The change is requested
>> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
>> > Unlike Clang, I chose to name it no_stack_protec
Hello,
On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
> > The patch adds new no_stack_protect attribute. The change is requested
> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
> > Unlike Clang, I chose to name it no_stack_protect because we already
> > h
On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > > The optimize attribute is used to specify that a function is to be
> > > compiled
> > > with different optimization options than specified on the command l
* Martin Liška:
> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_protect attribute (used with -fstack-protector-ex
On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > The optimize attribute is used to specify that a function is to be compiled
> > with different optimization options than specified on the command line.
> > ```
> >
> > It's pretty clear about the command line arguments (that are ig
On Mon, May 18, 2020 at 01:00:01PM +0200, Martin Liška wrote:
> On 5/18/20 12:41 PM, Jakub Jelinek wrote:
> > On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> > > The patch adds new no_stack_protect attribute. The change is requested
> > > from kernel folks and is direct equivalent o
On 5/18/20 12:41 PM, Jakub Jelinek wrote:
On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_prote
On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_prot
Hi.
The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used with -fstack-protector-explicit).
First par
36 matches
Mail list logo
