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
+ 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:
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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 simple enough
that it should work. Unless I'm
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
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
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
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
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
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
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
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
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
* 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
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
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
> >
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
* 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
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
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
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
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
35 matches
Mail list logo
