Hey,
>
> func_symbol:
> auipc t0, common_dispatch:high <=> j actual_func:
> jalr t0, common_dispatch:low(t0)
>
If you are patching in a jump, I don't see why you wouldn't jump over
ld+jalr? (no need for common dispatch)
Patching jalr with nop, and keeping auipc, addresses the issue with
having
On Tue, 12 Mar 2024 13:42:28 +
Mark Rutland wrote:
> There are ways around that, but they're complicated and/or expensive, e.g.
>
> * Use a sequence of multiple patches, starting with replacing the JALR with an
> exception-generating instruction with a fixup handler, which is sort-of what
Andy Chiu writes:
> On Thu, Mar 21, 2024 at 4:48 PM Björn Töpel wrote:
>>
>> Andy,
>>
>> Pulling out the A option:
>>
>> >> > A) Use auipc/jalr, only patch jalr to take us to a common
>> >> >dispatcher/trampoline
>> >> >
>> >> > | # probably on a data cache-line != func
>> >> > .text to
On Thu, Mar 21, 2024 at 4:48 PM Björn Töpel wrote:
>
> Andy,
>
> Pulling out the A option:
>
> >> > A) Use auipc/jalr, only patch jalr to take us to a common
> >> >dispatcher/trampoline
> >> >
> >> > | # probably on a data cache-line != func
> >> > .text to avoid ping-pong
> >> > | ...
>
On Tue, 12 Mar 2024 13:42:28 +
Mark Rutland wrote:
> > It would be interesting to see how the per-call performance would
> > improve on x86 with CALL_OPS! ;-)
>
> Heh. ;)
But this would require adding -fpatchable-function-entry on x86, which
would increase the size of text, which could
Mark,
Mark Rutland writes:
>> A) Use auipc/jalr, only patch jalr to take us to a common
>>dispatcher/trampoline
>>
>> | # probably on a data cache-line != func .text
>> to avoid ping-pong
>> | ...
>> | func:
>> | ...make sure ra isn't messed up...
>> | aupic
>> | nop <=>
Andy,
Pulling out the A option:
>> > A) Use auipc/jalr, only patch jalr to take us to a common
>> >dispatcher/trampoline
>> >
>> > | # probably on a data cache-line != func
>> > .text to avoid ping-pong
>> > | ...
>> > | func:
>> > | ...make sure ra isn't messed up...
>> > | aupic
On Thu, Mar 14, 2024 at 04:07:33PM +0100, Bj"orn T"opel wrote:
> After reading Mark's reply, and discussing with OpenJDK folks (who does
> the most crazy text patching on all platforms), having to patch multiple
> instructions (where the address materialization is split over multiple
>
Hi Björn,
On Fri, Mar 15, 2024 at 4:50 AM Björn Töpel wrote:
>
> Björn Töpel writes:
>
> > Puranjay Mohan writes:
> >
> >> Björn Töpel writes:
> >>
> >>>
> >>> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
> >>> trampolines changes quite a bit.
> >>>
> >>> The more I
Björn Töpel writes:
> Puranjay Mohan writes:
>
>> Björn Töpel writes:
>>
>>>
>>> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
>>> trampolines changes quite a bit.
>>>
>>> The more I look at the pains of patching two instruction ("split
>>> immediates"), the better
Puranjay Mohan writes:
> Björn Töpel writes:
>
>>
>> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
>> trampolines changes quite a bit.
>>
>> The more I look at the pains of patching two instruction ("split
>> immediates"), the better "patch data" + one insn patching
Björn Töpel writes:
>
> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic
> trampolines changes quite a bit.
>
> The more I look at the pains of patching two instruction ("split
> immediates"), the better "patch data" + one insn patching look.
I was looking at how dynamic
Mark Rutland writes:
> Hi Bjorn
>
> (apologies, my corporate mail server has butchered your name here).
Ha! That's the price I have to pay for carrying double-umlauts
everywhere. Thanks for getting back with a really useful answer!
>> On Arm64, CALL_OPS makes it possible to implement direct
Hi Bjorn
(apologies, my corporate mail server has butchered your name here).
There's a big info dump below; I realise this sounds like a sales pitch for
CALL_OPS, but my intent is more to say "here are some dragons you may not have
spotted".
On Thu, Mar 07, 2024 at 08:27:40PM +0100, Bj"orn
Hi,
On 07.03.2024 03:17, Puranjay Mohan wrote:
Hi Alex,
On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote:
Hi Puranjay,
On 06/03/2024 17:59, Puranjay Mohan wrote:
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
This allows each ftrace callsite to provide an
On Fri, Mar 08, 2024 at 05:18:21PM +0800, Andy Chiu wrote:
> Hi Puranjay,
>
> On Fri, Mar 8, 2024 at 3:53 AM Puranjay Mohan wrote:
> >
> > Hi Björn,
> >
> > On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
> > >
> > > Puranjay!
> > >
> > > Puranjay Mohan writes:
> > >
> > > > This patch
Puranjay Mohan writes:
>> Now, I think a better approach for RISC-V would be implementing what x86
>> has (arch_ftrace_update_trampoline()), rather than CALL_OPS for RISC-V.
>>
>> Thoughts?
>
> I am going to spin some patches for implementing
> arch_ftrace_update_trampoline() for
> RISC-V, then
Hi Björn,
On Fri, Mar 8, 2024 at 11:16 AM Björn Töpel wrote:
> >
> > If I remember from Steven's talk, x86 uses dynamically allocated trampolines
> > for per callsite tracers, would CALL_OPS provide better performance than
> > that?
>
> Probably not, and it was really a tongue-in-cheek comment
Hi Andy,
> >
> > I don't think implementing direct calls over call ops is fruitful for
> > RISC-V because once
> > the auipc/jalr can be patched atomically, the direct call trampoline
> > is always reachable.
>
> Yes, the auipc/jalr instruction pair can be patched atomically just as
> long as
Puranjay Mohan writes:
> Hi Björn,
>
> On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
>>
>> Puranjay!
>>
>> Puranjay Mohan writes:
>>
>> > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
>> > This allows each ftrace callsite to provide an ftrace_ops to the common
>> >
Hi Puranjay,
On Fri, Mar 8, 2024 at 3:53 AM Puranjay Mohan wrote:
>
> Hi Björn,
>
> On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
> >
> > Puranjay!
> >
> > Puranjay Mohan writes:
> >
> > > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > > This allows each ftrace
On Thu, Mar 7, 2024 at 8:19 AM Puranjay Mohan wrote:
>
> Hi Alex,
>
> On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote:
> >
> > Hi Puranjay,
> >
> > On 06/03/2024 17:59, Puranjay Mohan wrote:
> > > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > > This allows each
Hi Björn,
On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote:
>
> Puranjay!
>
> Puranjay Mohan writes:
>
> > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > This allows each ftrace callsite to provide an ftrace_ops to the common
> > ftrace trampoline, allowing each
Puranjay!
Puranjay Mohan writes:
> This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> This allows each ftrace callsite to provide an ftrace_ops to the common
> ftrace trampoline, allowing each callsite to invoke distinct tracer
> functions without the need to fall back to
Hi Alex,
On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote:
>
> Hi Puranjay,
>
> On 06/03/2024 17:59, Puranjay Mohan wrote:
> > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
> > This allows each ftrace callsite to provide an ftrace_ops to the common
> > ftrace
+cc Andy and Evgenii
On 06/03/2024 21:35, Alexandre Ghiti wrote:
Hi Puranjay,
On 06/03/2024 17:59, Puranjay Mohan wrote:
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
This allows each ftrace callsite to provide an ftrace_ops to the common
ftrace trampoline, allowing
Hi Puranjay,
On 06/03/2024 17:59, Puranjay Mohan wrote:
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
This allows each ftrace callsite to provide an ftrace_ops to the common
ftrace trampoline, allowing each callsite to invoke distinct tracer
functions without the need
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V.
This allows each ftrace callsite to provide an ftrace_ops to the common
ftrace trampoline, allowing each callsite to invoke distinct tracer
functions without the need to fall back to list processing or to
allocate custom
28 matches
Mail list logo
