Re: [PATCH] gas: retain whitespace between strings

[Jan Beulich <jbeulich@suse.com>]

Nick,

On 16.03.2022 17:55, Nick Clifton wrote:
>> Change the scrubber to retain such whitespace, by making the processing
>> of strings more similar to that of symbols. And indeed this appears to
>> make sense when taking into account that for quite a while gas has been
>> supporting quoted symbol names.
> 
> OK, that makes sense.
> 
>> Taking a more general view, however, the change doesn't go quite far
>> enough. There are further cases where significant whitespace is removed
>> by the scrubber. The new testcase enumerates a few in its ".if 0"
>> section. I'm afraid the only way that I see to deal with this would be
>> to significantly simplify the scrubber, such that it wouldn't do much
>> more than collapse sequences of unquoted whitespace into a single blank.
>> To be honest problems in this area aren't really surprising when seeing
>> that there's hardly any checking of .macro use throughout the testsuite
>> (and in particular in the [relatively] generic tests under all/).
> 
> Plus assembler macro syntax has never been that well specified.
> 
> 
>> Partly RFC: While I did test this for x86, I didn't get around yet to
>> run a much wider set of tests.
> 
> I ran my regression tester with the patch applied and nothing turned up,
> so I am happy to approve the patch.

Thanks. I did meanwhile get around to do a full run as well, but for
now I can only say "likely nothing turned up" because I did this with
"ELF32: don't silently truncate relocation addends" also in place.
The regressions found are likely all from this 2nd patch (matching
what Alan did point out already). But I didn't get around yet to
inspect the test failures individually.

>  One thing though - I think that it
> would be a good idea to extend the documentation to cover this behaviour.
> I do not mind if you do that as a separate patch, or just an extension
> to this one, but I think that it should be done.

Hmm, I would probably want to fold a related doc change into the patch
right away, but I'm having trouble seeing where this behavior would
sensibly be described. It's an implementation detail, after all, which
simply ended up broken internally. The behavior can't be described for
any directive in particular (or for insns in general), and whether
adjacent strings (irrespective of the intervening whitespace) are
concatenated is directive-dependent.

Or did you mean me to merely describe the specific behavior for .macro,
leaving aside potential effects elsewhere?

Jan