[PATCH v4 12/12] RISC-V: fix auipc-jalr addresses in patched alternatives

Conor.Dooley at microchip.com Conor.Dooley at microchip.com
Wed Dec 7 21:03:15 PST 2022


On 07/12/2022 22:37, Heiko Stuebner wrote:
> Am Mittwoch, 7. Dezember 2022, 21:48:08 CET schrieb Conor Dooley:
>> On Wed, Dec 07, 2022 at 07:08:21PM +0100, Heiko Stuebner wrote:
>>> From: Heiko Stuebner <heiko.stuebner at vrull.eu>

>>> +void riscv_alternative_fix_offsets(void *alt_ptr, unsigned int len,
>>> +                                 int patch_offset)
>>> +{
>>> +   int num_instr = len / sizeof(u32);
>>
>> instr...
>>
>>> +   int i;
>>> +
>>> +   /*
>>> +    * stop one instruction before the end, as we're checking
>>> +    * for auipc + jalr
>>> +    */
>>> +   for (i = 0; i < num_instr; i++) {
>>> +           u32 inst = riscv_instruction_at(alt_ptr + i * sizeof(u32));
>>
>> ...inst...
>>
>>> +
>>> +           /* may be the start of an auipc + jalr pair */
>>> +           if (riscv_insn_is_auipc(inst) && i < num_instr - 1) {
>>
>> ...insn.
>>
>> Is there a reason for that?
> 
> I guess more of a generational issue - with the code spanning
> too much time :-)
> 
> So poll question, what would be preferred?
> I think I remember seeing all of them somewhere, so I'm unsure what
> to standardize on.

I'd vote for insn, since it's used in the functions you're calling.

>> Also, I've gotten myself slightly confused about the loop. You "stop one
>> instruction before the end" but the main loop goes from 0 -> num_instr.
>> The inner loop then checks for i < num_instr - 1. What am I missing that
>> prevents the outer loop from stopping at num_instr - 1 instead?
> 
> The idea with this is to allow a
>          if(riscv_insn_is_jal(inst))
>                  riscv_alternative_fix_jal(...)
> 
> etc, and everything else is a single instruction so needs one more
> loop iteration, only for auipc+jalr do we want to stop one earlier.
> 
> So to get this alternatives_fix_offsets() main entry point I
> made the loop do the one iteration more again.

Right, fair enough in my book :)

Thanks,
Conor.





More information about the linux-riscv mailing list