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
27 matches
Mail list logo