[RFC PATCH] gas: Do not eliminate '\()' if there is still .irp is not fully translated

[Jan Beulich]

On 06.09.2024 09:41, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, September 6, 2024 3:32 PM
>>
>> On 06.09.2024 08:50, Haochen Jiang wrote:
>>> Recently I found that if I am using nested .irp with \(), it would be wrongly
>>> translated. It is caused by \() being eliminated too early. I tried with the
>>> following patch to add an extra bool passing in sub_actual to record if there
>>> is any .irp in mnemonic not handled before \() is handled.
>>>
>>> The patch works for current x86 testcases. I may also try with aarch64
>> machines
>>> if I could find one since macros are widely used in aarch testcases.
>>>
>>> I suppose there might be a better option to do that so I called this an RFC
>>> patch. The current method is quite straight-forward but seems too
>>> straight-forward. Discussion is welcomed.
>>
>> I don't think this should be done. If such a construct is to survive the
>> first round of expansion, it simply needs further escaping. With what you
>> do, if I'm not mistaken you'd break possible existing uses. (Aiui you
>> don't really look for just \(), but any \(...). Which of course is correct
>> as far as not special casing the one form goes. But what's inside \(...)
>> may be intended to be processed in the first round, for the 2nd expansion
>> round to use the result with \( and ) already dropped.
> 
> I c. I suppose maybe I should only keep \(). The current change impacts too
> much, which impacts \(...). This is not what I expected to do.

Yet as said - dealing with just \() is too narrow a special case. Plus even
that separator may be intended to be processed the 1st time round, and the
2nd round then using the result. You really want to change your use of the
construct to become \\(). No need to touch how macro expansion works.

Jan