[PATCH] PR32705 opcodes: fix RISC-V $x mapping symbol

[Nelson Chu]

I will discuss with others and then take care of the remaining work, and
don't worry, I will keep you as the main contributor of your dis-assembler
patch.

Thanks for sending the patch and point this problem
Nelson

On Tue, Feb 18, 2025 at 2:25 AM Andrew Oates <andrew@andrewoates.com> wrote:

>
>
> On Mon, Feb 17, 2025 at 1:18 PM Andrew Oates <andrew@andrewoates.com>
> wrote:
>
>>
>>
>> On Sun, Feb 16, 2025 at 11:41 PM Andrew Oates <andrew@andrewoates.com>
>> wrote:
>>
>>> (+ binutils@sourceware.org which I accidentally dropped in my earlier
>>> reply)
>>>
>>> On Sun, Feb 16, 2025, 23:02 Nelson Chu <nelson@rivosinc.com> wrote:
>>>
>>>> Well if I remember correctly, assembler generates $x means it is the
>>>> same as the previous $x<isa>, and that conflicts with what psABI defined.
>>>> If we are using a new objdump which follows the current psABI, then using
>>>> it to dump the old packages will be wrong, and that's the problem is.
>>>>
>>>
>>> Ah, I see what you mean.  I didn't realize there was an ABI change.
>>>
>>> I haven't observed this behavior in practice but looking at the code I
>>> think you're right, it could emit $x when the isa hasn't changed but isn't
>>> the same as the ELF default.
>>>
>>> I'll definitely defer to this group on the right approach :)
>>>
>>> Any suggestions on how to write a test case to trigger this scenario? I
>>> played around with the gas and binutils test cases quite a bit but
>>> struggled to get gas to emit a $x in any interesting way.
>>>
>>
>> Would fixing this part of gas be as simple as plumbing the default arch
>> string through, then replacing "strcmp (riscv_rps_as.subset_list->arch_str,
>> ..." with "strcmp (riscv_rps_as.default_arch, ..." in
>> riscv_mapping_state()?
>>
>> I'm not at all familiar with the gas codebase so any pointers would be
>> very helpful.
>>
>
> Actually, thinking about this more, the linker has to be updated as well,
> right?  If $x resets to the default architecture of the ELF file, that
> could change when multiple object files with different defaults are linked
> together, so the linker would need to go and update symbols in sections
> that use the "wrong" default to be explicit.  I have not even started
> looking at the ld code :)
>
> This is probably not a huge issue in practice today, and gas emits
> explicit $xrv... symbols at the start of each section, and I imagine that
> changing architectures within a section is...unusual (what is the use case
> for that?).
>
> Let me know if we should take this discussion to a riscv ABI forum rather
> than binutils (and if so, which one).  My tactical goal is just to be able
> to disassemble my current binaries compiled by LLVM without half the
> instructions being ".insn", but there may be some bigger questions here to
> resolve.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250218/ea4ab3f7/attachment.htm>