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

[Jan Beulich <jbeulich@suse.com>]

Nick,

On 13.03.2023 13:06, Nick Clifton wrote:
>> 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.

okay, this addresses the first of the two points raised and indicates
that while things look somewhat odd, they really are okay in this regard.
I have to admit though that I don't follow why you specially mention
control character use by a backend as fake label name, not the least
since it's the default that a control character is used.

What I don't think you addressed is my 2nd observation wrt quoted symbol
names. There all characters can appear in symbol names, and hence
deriving "local" (or not) based on symbol name looks wrong to me.

Jan