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

[Jan Beulich]

On 30.03.2023 14:01, Jan Beulich wrote:
> 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.

All,

with 2.41 out of the way, may I ask that we make some progress here? All
I got back so far was agreement that the situation isn't nice. But that
doesn't help determining how to improve things (a) without too much
breakage and (b) with the goal of not needing to redo this yet again
later.

Thanks, Jan