[PATCH RFC] RISC-V: alter the special character used in FAKE_LABEL_NAME

[Jan Beulich]

On 10.03.2023 10:36, Jan Beulich via Binutils wrote:
> The use of a space char there collides with anything using temp_ilp(),
> i.e. at present at least with the special % operator available in
> alternate macro mode. Further uses of the function may appear at any
> time. This likely is a result of write.h's comment not properly
> spelling out all the constraints placed on the selection of the special
> character used. Then again RISC-V anyway violates a constraint which has
> been properly spelled out there: Such labels _do_ appear in assembler
> output.
> ---
> RFC: Of course this breaks interoperability between older gas / new
>      objdump and vice versa. But I don't see a way to resolve the issue
>      at hand without introducing such a discontinuity. To limit "damage"
>      a little, riscv_symbol_is_valid() could of course be tought to also
>      ignore old style fake label names. (Personally I view this tying of
>      functionality between assembler and disassembler as problematic
>      anyway.) Thoughts?
> 
> I question the use of FAKE_LABEL_NAME in make_internal_label(). The
> comment in tc-riscv.h isn't correct anyway because of (at least) this
> use - the symbols generated there are never used for Dwarf. And them all
> being the same makes it rather hard to associate relocations resolved to
> symbol names (e.g. "objdump -dr" output) with the actual instance that's
> referenced. Their naming should imo rather follow the model of
> {fb,dollar}_label_name().

I wanted to further mention the following: Using '?' or really any
printable character has the downside of (pretty much) closing the road
of making such characters usable in normal (unquoted) symbols. '?' in
particular is, at least on x86, used e.g. in Microsoft VC's C++ name
mangling scheme. Yet as per the comment in tc-riscv.h it is specifically
a goal to use a printable character here.

Jan