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

Jiang, Haochen haochen.jiang@intel.com
Fri Sep 6 07:47:50 GMT 2024


> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, September 6, 2024 3:46 PM
> 
> 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.

Aha, that is a good point. It should work and then no need to change all of
them.

Thx,
Haochen

> 
> Jan


More information about the Binutils mailing list