Re: [PATCH] RISC-V: fix JAL aliases ordering in opcode table

[Jan Beulich <jbeulich@suse.com>]

On 05.01.2023 08:56, Aurelien Jarno wrote:
> On 2023-01-04 08:50, Jan Beulich via Binutils wrote:
>> On 04.01.2023 06:59, Aurelien Jarno wrote:
>>> Commit 839189bc932e ("RISC-V: re-arrange opcode table for consistent
>>> alias handling") reorder the instructions in the opcode tables,
>>> including the various JAL aliases. In particular they are not ordered
>>> anymore from the most specific to the less specific one. This causes the
>>> form "JAL reg, imm" to emit a relocation with the register name. This
>>> breaks various things like building Linux kernel modules.
>>>
>>> This patch fixes the issue by restoring the original ordering of the JAL
>>> aliases.
>>
>> I'm afraid reverting the "offending" hunk is only a workaround, as it
>> would re-introduce the disassembler side issue that the patch tried to
>> deal with (and which sadly looks to not be covered by anything in the
>> testsuite, or else you would have noticed breakage when testing your
>> change). Since I expect that in the course of table lookup it is still
>> the correct entry (in particular one with two rather than just one
>> operands) which is used, my suspicion is that something somewhere makes
>> a silent assumption upon the (original) ordering of table entries. It
>> would be that place which needs fixing then; I'll try to find time soon
>> to see if I can spot where that is.
> 
> Thanks for the analysis. Do you think you have time to get a patch with
> that fix before the 2.40 release?

I hope to get to looking into this tomorrow; whether that'll result in a
patch I obviously can't tell yet. In any event Nelson's reply (which
crossed with mine) suggests the reason for the problem to be different.
Yet then still that's where the change wants to be (albeit I disagree
with his proposal, yet that's without having looked at the code at all),
rather than re-introducing the disassembler inconsistency. The latter
would certainly be a short-term option for the impending release, if a
proper solution can't be found in time or turns out too intrusive. But
then the title and description would need adjustment to reflect this
(e.g. it wouldn't be "fix" but maybe "restore" or "undo").

Jan