RISC-V: attributes and assembly / disassembly

[Nelson Chu]

There was a prototype,
https://sourceware.org/pipermail/binutils/2022-August/122220.html.
The updated_riscv_subsets boolean avoids generating repeated mapping
symbols with ISA ($xrv...), if the ISA is the same as file-level elf
architecture attribute or the previous one.  But in practice there is
a bug in that prototype - we still need to generate $x or $xrv... when
it is at the start address of sections, even if it has the same ISA.
Let me see if I can find a better solution for the problem, maybe each
segment should have its own updated_riscv_subsets boolean or ISA
string.

Thanks
Nelson

On Tue, Sep 13, 2022 at 3:42 AM Kito Cheng <kito.cheng@gmail.com> wrote:
>
> A quick answer is that should be addressed by mapping symbol, but I am not sure the current implementation status in binutils side, Nelson might be able to answer this.
>
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/196
>
> Jan Beulich via Binutils <binutils@sourceware.org> 於 2022年9月12日 週一 18:14 寫道：
>>
>> Hello,
>>
>> for use in other work I've been playing with this piece of assembly code
>>
>>         .option push
>>         .option arch, +c
>> aliasC:
>>         sll     x1, x1, 3
>>         c.slli  x1, 3
>>         sra     x8, x8, 3
>>         c.srai  x8, 3
>>         srl     x8, x8, 3
>>         c.srli  x8, 3
>>         .option pop
>>
>> ending up quite surprised that the resulting object doesn't disassemble
>> (at least not without giving the disassembler extra options). It then
>> occurred to me to drop the push/pop of the options, and voila - things
>> worked. Aiui riscv_write_out_attrs() populates Tag_RISCV_arch with the
>> state of things at the end of assembly. Which raises (at least) two
>> questions:
>>
>> 1) Shouldn't the assembler accumulate all extensions which were ever
>> enabled in the course of processing the source, and use that set to
>> populate Tag_RISCV_arch? Even if that's too simplistic, I don't think
>> the state of things at the end of assembly can be taken as
>> representative for the entire object.
>>
>> 2) The assembler properly sets the RVC bit in the ELF flags in the
>> case described. Shouldn't the disassembler use that information
>> alongside the attributes section?
>>
>> Thanks for any insight,
>> Jan