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

[Nick Clifton <nickc@redhat.com>]

Hi Jan,

> On 10.03.2023 10:36, Jan Beulich via Binutils wrote:
>> Considering the special casing of FAKE_LABEL_CHAR in read_symbol_name()
>> and get_symbol_name() I wonder in how far LOCAL_LABEL_CHAR and/or
>> DOLLAR_LABEL_CHAR don't also need recognizing there (and then also be
>> marked in lex[] just like done here). I can't point out a specific case
>> though where there could be a problem.
>>
>> The checking for *_LABEL_CHAR in S_IS_LOCAL() looks to collide with uses
>> of these characters in quoted symbol names.
> 
> while the rest of the open questions is RISC-V specific, these two items
> are not, and since from the title I suppose you may not notice the generic
> aspects here, I thought I'd point them out explicitly. Just in case you
> have any thoughts there (if you don't, I'm not sure how to progress).

Thanks for bringing this up, and you are right, I had not noticed these
generic questions.  My thoughts on this topic are as follows:

I think that the intention of FAKE_LABEL_CHAR is to allow backends to
generate labels contains characters that are not normally accepted as
part of a label's name, but which nevertheless should be treated as if
they were real user-provided names.  The LOCAL_LABEL_CHAR and
DOLLAR_LABEL_CHAR characters on the other hand are intended solely for
internal assembler use and should never appear in user-generated, or
backend-generated labels.  Hence it makes sense to check for
FAKE_LABEL_CHAR to be checked in functions that read user labels
(read.c:read_symbol_name(), expr.c:get_symbol_name()) and it also makes
sense to not check for - and by implication, reject - LOCAL_LABEL_CHAR
and DOLLAR_LABEL_CHAR.

There is a special case however.  If a backend does not define
FAKE_LABEL_NAME (and FAKE_LABEL_CHAR) then write.h will define them
instead and it will use the same default character as DOLLAR_LABEL_CHAR.
I am not sure why this was done, possibly it was a mistake - it might
have been better to use a different control character, eg '\0003' instead.
Anyway, the header is written that way at the moment, and this is why
there is a (not actually needed) check in S_IS_LOCAL() for DOLLAR_LABEL_
CHAR and FAKE_LABEL_CHAR being the same.

So in conclusion, I think that unless a backend wants to use a control
character as a fake label name character, there should be no problems.

Cheers
   Nick