[PATCH 1/2] RISC-V: Stop generating mapping symbol $x, replace with $x<isa>.

[Nelson Chu]

On Sat, Feb 22, 2025 at 5:12 AM Andrew Oates <andrew@andrewoates.com> wrote:

>
>
> On Fri, Feb 21, 2025, 02:33 Nelson Chu <nelson@rivosinc.com> wrote:
>
>> The psABI defined $x to the architecture which is same as the file elf
>> attribute.  But GNU defined it to that is same as the previous $x<isa>,
>> and always generated $x<isa> at the begining of each section.  That is
>> because considering two objects have different architecture in their elf
>> attributes, then $x will always be wrong after linking since the merged
>> arch string will be changed.  For example, object A with rv32ic and object
>> B with rv32ia, $x from A is rv32ic and $x from B is rv32ia, but the final
>> output is rv32ica, so $x from A and B need to be updated to rv32ic and
>> rv32ia by linker respectively.  I think let linker to do this is not good,
>> so in order to follow the psABI, we will stop generating the $x for now.
>> Instead, all $x will be replaced with the corresponding $x<isa>.  The
>> dis-assembler will also treat $x like what psABI defined.
>>
>
> I agree this is a lot of work for the linker, but it has to do it anyway,
> right? Otherwise it won't be able to correctly link psABI-compliant objects
> generated by other tool chains (like llvm). Or is that a non-goal?
>

Well since psABI seems not yet define these, so lld should also meet the
same problem.  Of course, it is best for both gnu and llvm to have the same
behavior, but considering that both sides have their own ideas, the
undefined behavior itself has a certain degree of flexibility, as long as
it does not violate the behavior defined by the specification.  These two
patches (especially yours) are only intended to fix spec violations in GNU.


> Alternatively: given the merging rules for the architecture strings when
> linking objects files together, can we just say that having the linker
> leave $x alone is always correct as it will refer to a superset
> architecture strings of whatever the original is? (assuming there are no
> incompatibilities, but that should be easily detected anyway)
>

It's welcome to share these in the psABI.  I don't have an idea for now,
but I am happy to see maybe psABI, toolchain convention, or whatever spec
will define the behavior that everyone should follow.

Thanks
Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250224/9b535198/attachment-0001.htm>