On Wed, Jun 10, 2015 at 11:24:05AM -0700, Andy Lutomirski wrote:
> Slightly off-topic, but this reminds me: when writing inline asm that
> needs to push to the stack (for whatever reason), it's incredibly
> messy to get the annotations right -- they're different depending on
> whether the previous
On Wed, Jun 10, 2015 at 12:38:32PM -0700, Andy Lutomirski wrote:
> On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf wrote:
> > On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
> >> Josh Poimboeuf writes:
> >>
> >> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> >> >> >
On Wed, Jun 10, 2015 at 11:41:43AM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
> >
> > If you're wanting something like -freorder-blocks-and-partition for asm
> > code, maybe we could implement something analagous to the
> > likely()/unlikely() macros, to allow the hot and cold portions to b
On Wed, Jun 10, 2015 at 12:36 PM, Josh Poimboeuf wrote:
> On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
>> Josh Poimboeuf writes:
>>
>> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
>> >> > > > - duplicate the destination code inside the function
>> >> > > > - conver
On Wed, Jun 10, 2015 at 11:40:06AM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
>
> > On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> >> > > > - duplicate the destination code inside the function
> >> > > > - convert the jump to a call
> >> > >
> >> > > That all won't work for
Josh Poimboeuf writes:
>
> If you're wanting something like -freorder-blocks-and-partition for asm
> code, maybe we could implement something analagous to the
> likely()/unlikely() macros, to allow the hot and cold portions to be
> placed into different sections. (I could then teach asmvalidate h
Josh Poimboeuf writes:
> On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
>> > > > - duplicate the destination code inside the function
>> > > > - convert the jump to a call
>> > >
>> > > That all won't work for a lot of cases.
>> >
>> > Hm, could you give an example?
>>
>> Just a s
On Wed, Jun 10, 2015 at 5:06 AM, Josh Poimboeuf wrote:
> The previous version of this patch set was named "Compile-time stack
> frame pointer validation". I changed the subject from "frame pointer
> validation" to "asm code validation" because the focus of the patch set
> has changed to be less f
On Wed, Jun 10, 2015 at 10:31:55AM -0500, Josh Poimboeuf wrote:
> On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> > It's not needed, but it's an optimization to optimize icache usage.
> > It is optional (-freorder-blocks-and-partition)
> >
> > In this case gcc splits the function int
On Wed, Jun 10, 2015 at 05:04:12PM +0200, Andi Kleen wrote:
> > > > - duplicate the destination code inside the function
> > > > - convert the jump to a call
> > >
> > > That all won't work for a lot of cases.
> >
> > Hm, could you give an example?
>
> Just a standard *_user exception handler.
> > > - duplicate the destination code inside the function
> > > - convert the jump to a call
> >
> > That all won't work for a lot of cases.
>
> Hm, could you give an example?
Just a standard *_user exception handler.
>
> Well, I don't see how that's really a logical conclusion.
What's spe
On Wed, Jun 10, 2015 at 04:11:04PM +0200, Andi Kleen wrote:
> > In most cases there are ways to keep the optimizations. For example:
> >
> > - grow the function bounds to keep the jump internal
>
> So you mean moving it after the ret? That still means icache bloat.
No, in most cases it just mea
On Wed, Jun 10, 2015 at 03:42:41PM +0200, Pavel Machek wrote:
> On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
> > The previous version of this patch set was named "Compile-time stack
> > frame pointer validation". I changed the subject from "frame pointer
> > validation" to "asm code validatio
> In most cases there are ways to keep the optimizations. For example:
>
> - grow the function bounds to keep the jump internal
So you mean moving it after the ret? That still means icache bloat.
> - duplicate the destination code inside the function
> - convert the jump to a call
That all won
On Wed, Jun 10, 2015 at 03:08:14PM +0200, Andi Kleen wrote:
>
> > 2. Each callable function must never leave its own bounds (i.e. with a
> >jump to outside the function) except when returning.
>
> That prevents a lot of optimizations with out of line code.
In most cases there are ways to kee
On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
> The previous version of this patch set was named "Compile-time stack
> frame pointer validation". I changed the subject from "frame pointer
> validation" to "asm code validation" because the focus of the patch set
> has changed to be less frame p
> 2. Each callable function must never leave its own bounds (i.e. with a
>jump to outside the function) except when returning.
That prevents a lot of optimizations with out of line code.
In fact even gcc with the right options can generate code that violates
this. Standard Linux construction
On Wed, Jun 10, 2015 at 07:06:08AM -0500, Josh Poimboeuf wrote:
> There are still a lot of outstanding warnings (which I'll paste as a
> reply to this email). Once those are all cleaned up, we can change the
> warnings to build errors and change the default to
> CONFIG_ASM_VALIDATION=y so the asm
The previous version of this patch set was named "Compile-time stack
frame pointer validation". I changed the subject from "frame pointer
validation" to "asm code validation" because the focus of the patch set
has changed to be less frame pointer-focused and more asm-focused. I
also renamed the t
19 matches
Mail list logo
