On 20/04/16 02:25, AKASHI Takahiro wrote:
> On Tue, Apr 19, 2016 at 09:39:39AM +0300, Alexander Monakov wrote:
>> On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
> But if Szabolcs' two-instruction
> sequence in the adjacent subthread is sufficient, this is moot.
. It can also be sol
On 20/04/16 01:36, AKASHI Takahiro wrote:
> On Tue, Apr 19, 2016 at 09:44:37AM +0300, Alexander Monakov wrote:
>> On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
looking at [2] i don't see why
func:
mov x9, x30
bl _tracefunc
>>>
>>> Actually,
>>> mov x9, x30
>>>
On Tue, Apr 19, 2016 at 09:39:39AM +0300, Alexander Monakov wrote:
> On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
> > > > But if Szabolcs' two-instruction
> > > > sequence in the adjacent subthread is sufficient, this is moot.
> > >
> > > . It can also be solved by having just one NOP after the f
On Tue, Apr 19, 2016 at 09:44:37AM +0300, Alexander Monakov wrote:
> On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
> > > looking at [2] i don't see why
> > >
> > > func:
> > > mov x9, x30
> > > bl _tracefunc
> > >
> >
> > Actually,
> > mov x9, x30
> > bl _tracefunc
> > mov x30, x
On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote:
>
> . It can also be solved by having just one NOP after the function label,
> and a number of them before, then no thread can be in the nop pad. That
> seems to indicate that GCC should not try to be too clever and simply
> leave
On 04/19/2016 03:37 PM, Pedro Alves wrote:
> On 04/19/2016 02:25 PM, Andrew Haley wrote:
>> On 04/19/2016 02:19 PM, Michael Matz wrote:
>>
>>> Well, yeah, that's traditional insn caches on multiple cores. From
>>> user space you need kernel help for this, doing interprocess
>>> interrupts to flush
On 04/19/2016 02:25 PM, Andrew Haley wrote:
> On 04/19/2016 02:19 PM, Michael Matz wrote:
>
>> Well, yeah, that's traditional insn caches on multiple cores. From
>> user space you need kernel help for this, doing interprocess
>> interrupts to flush all such buffers on all cores (or at least those
On 04/19/2016 02:19 PM, Michael Matz wrote:
> Well, yeah, that's traditional insn caches on multiple cores. From
> user space you need kernel help for this, doing interprocess
> interrupts to flush all such buffers on all cores (or at least those
> potentially fetching stuff in the patched region
Hi,
On Tue, 19 Apr 2016, Andrew Haley wrote:
> > I will happily declare any implementation where it's impossible to
> > safely patch the instruction stream by flushing the respective buffers
> > or other means completely under control of the patching machinery, to
> > be broken by design.
>
>
On 18/04/16 18:34, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Apr 2016, Andrew Haley wrote:
>
That may not be safe. Consider an implementation which looks
ahead in the instruction stream and decodes the instructions
speculatively.
>>>
>>> It should go without saying that patching in
On Mon, Apr 18, 2016 at 06:54:33PM +0300, Alexander Monakov wrote:
> On Mon, 18 Apr 2016, Szabolcs Nagy wrote:
> > On 18/04/16 14:26, Alexander Monakov wrote:
> > > On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
> > >> looking at [2] i don't see why
> > >>
> > >> func:
> > >> mov x9, x30
> > >> bl _
On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
> > looking at [2] i don't see why
> >
> > func:
> > mov x9, x30
> > bl _tracefunc
> >
>
> Actually,
> mov x9, x30
> bl _tracefunc
> mov x30, x9
>
I think here Szabolcs' point was that the last instruction can be eliminated:
_tr
On Tue, 19 Apr 2016, AKASHI Takahiro wrote:
> > > But if Szabolcs' two-instruction
> > > sequence in the adjacent subthread is sufficient, this is moot.
> >
> > . It can also be solved by having just one NOP after the function label,
> > and a number of them before, then no thread can be in the
On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote:
> Hi,
>
> On Sun, 17 Apr 2016, Alexander Monakov wrote:
>
> > I've noticed an issue in my (and probably Michael's) solution: if
> > there's a thread that made it past the first nop, but is still executing
> > the nop pad, it's unsafe
On Thu, Apr 14, 2016 at 04:58:12PM +0100, Szabolcs Nagy wrote:
> On 14/04/16 14:15, Andrew Pinski wrote:
> > On Thu, Apr 14, 2016 at 9:08 PM, Maxim Kuvyrkov
> > wrote:
> >> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
> >>>
> >>> As ARM64 is entering enterprise world, machines can not be stopped f
On Thu, Apr 14, 2016 at 04:08:23PM +0300, Maxim Kuvyrkov wrote:
> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
> >
> > As ARM64 is entering enterprise world, machines can not be stopped for
> > some critical enterprise production environment, that is, live patch as
> > one of the RAS features is i
Hi,
On Mon, 18 Apr 2016, Andrew Haley wrote:
> >> That may not be safe. Consider an implementation which looks ahead
> >> in the instruction stream and decodes the instructions speculatively.
> >
> > It should go without saying that patching instructions is followed by
> > whatever means nece
On 04/18/2016 06:13 PM, Michael Matz wrote:
> On Mon, 18 Apr 2016, Andrew Haley wrote:
>
>> On 04/15/2016 06:29 PM, Alexander Monakov wrote:
>>
>>> Alternatively: replace first nop with a short forward branch that
>>> jumps over the rest of the pad, patch rest of the pad, patch the
>>> initial fo
Hi,
On Mon, 18 Apr 2016, Andrew Haley wrote:
> On 04/15/2016 06:29 PM, Alexander Monakov wrote:
>
> > Alternatively: replace first nop with a short forward branch that
> > jumps over the rest of the pad, patch rest of the pad, patch the
> > initial forward branch.
>
> That may not be safe. Con
On Mon, 18 Apr 2016, Szabolcs Nagy wrote:
> On 18/04/16 14:26, Alexander Monakov wrote:
> > On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
> >> looking at [2] i don't see why
> >>
> >> func:
> >> mov x9, x30
> >> bl _tracefunc
> >>
> >>
> >> is not good for the kernel.
> >>
> >> mov x9, x30 is a
On 04/15/2016 06:29 PM, Alexander Monakov wrote:
> Alternatively: replace first nop with a short forward branch that
> jumps over the rest of the pad, patch rest of the pad, patch the
> initial forward branch.
That may not be safe. Consider an implementation which looks ahead in
the instruction
On 18/04/16 14:26, Alexander Monakov wrote:
> On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
>> looking at [2] i don't see why
>>
>> func:
>> mov x9, x30
>> bl _tracefunc
>>
>>
>> is not good for the kernel.
>>
>> mov x9, x30 is a nop at function entry, so in
>> theory 4 byte atomic write should
On Mon, 18 Apr 2016, Ramana Radhakrishnan wrote:
> > - and GCC is not smart enough to be aware that intra-TU calls to 'func' (the
> > function we're instrumenting) don't touch x16/x17. And GCC should be that
> > smart, if it's not, it's a bug, right? :)
> >
>
> That it already is - IIRC. Oth
On 18/04/16 14:44, Alexander Monakov wrote:
> On Mon, 18 Apr 2016, Ramana Radhakrishnan wrote:
>> On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov
>> wrote:
>>> On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
looking at [2] i don't see why
func:
mov x9, x30
bl _tracefun
On Mon, 18 Apr 2016, Ramana Radhakrishnan wrote:
> On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov wrote:
> > On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
> >> looking at [2] i don't see why
> >>
> >> func:
> >> mov x9, x30
> >> bl _tracefunc
> >>
> >>
> >> is not good for the kernel.
> >>
On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov wrote:
> On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
>> looking at [2] i don't see why
>>
>> func:
>> mov x9, x30
>> bl _tracefunc
>>
>>
>> is not good for the kernel.
>>
>> mov x9, x30 is a nop at function entry, so in
>> theory 4 byte atomi
On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
> looking at [2] i don't see why
>
> func:
> mov x9, x30
> bl _tracefunc
>
>
> is not good for the kernel.
>
> mov x9, x30 is a nop at function entry, so in
> theory 4 byte atomic write should be enough
> to enable/disable tracing.
Overwriting x9
Hi,
On Sun, 17 Apr 2016, Alexander Monakov wrote:
> I've noticed an issue in my (and probably Michael's) solution: if
> there's a thread that made it past the first nop, but is still executing
> the nop pad, it's unsafe to replace the nops. To solve that, it
> suffices to have a forward branc
On Fri, 15 Apr 2016, Alexander Monakov wrote:
> On Fri, 15 Apr 2016, Michael Matz wrote:
> > Replace first nop with a breakpoint, handle rest of patching in breakpoint
> > handler, patch breakpoint insn last, no need to atomically patch multiple
> > instructions.
>
> Alternatively: replace first
On Fri, 15 Apr 2016, Michael Matz wrote:
> On Thu, 14 Apr 2016, Maxim Kuvyrkov wrote:
>
> > It appears that implementing -fprolog-pad=N option in GCC will not
> > enable kernel live-patching support for AArch64. The proposal for the
> > option was to make GCC output a given number of NOPs at th
Hi,
On Thu, 14 Apr 2016, Maxim Kuvyrkov wrote:
> It appears that implementing -fprolog-pad=N option in GCC will not
> enable kernel live-patching support for AArch64. The proposal for the
> option was to make GCC output a given number of NOPs at the beginning of
> each function, and then the
On 14/04/16 14:15, Andrew Pinski wrote:
> On Thu, Apr 14, 2016 at 9:08 PM, Maxim Kuvyrkov
> wrote:
>> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>>>
>>> As ARM64 is entering enterprise world, machines can not be stopped for
>>> some critical enterprise production environment, that is, live patch
On Thu, Apr 14, 2016 at 9:08 PM, Maxim Kuvyrkov
wrote:
> On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>>
>> As ARM64 is entering enterprise world, machines can not be stopped for
>> some critical enterprise production environment, that is, live patch as
>> one of the RAS features is increasing mor
On Mar 14, 2016, at 11:14 AM, Li Bin wrote:
>
> As ARM64 is entering enterprise world, machines can not be stopped for
> some critical enterprise production environment, that is, live patch as
> one of the RAS features is increasing more important for ARM64 arch now.
>
> Now, the mainstream live
As ARM64 is entering enterprise world, machines can not be stopped for
some critical enterprise production environment, that is, live patch as
one of the RAS features is increasing more important for ARM64 arch now.
Now, the mainstream live patch implementation which has been merged in
Linux kerne
From: Jiangjiji
* gcc/config/aarch64/aarch64.opt: Add a new option.
* gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
* gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFILER.
Signed-off-by: Jiangjiji
Signed-off-by: Li Bin
---
gcc/config/aarch64/aarch64.c |
On 22 October 2015 at 14:21, Li Bin wrote:
> From: Jiangjiji
>
> * gcc/config/aarch64/aarch64.opt: Add a new option.
> * gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
> * gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFILER.
>
> Signed-off-by: Jiangjiji
> Si
From: Jiangjiji
* gcc/config/aarch64/aarch64.opt: Add a new option.
* gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
* gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFILER.
Signed-off-by: Jiangjiji
Signed-off-by: Li Bin
---
gcc/config/aarch64/aarch64.c |
38 matches
Mail list logo
