Re: [PATCH,V3 00/13] Synthesize CFI for hand-written asm

[Jan Beulich <jbeulich@suse.com>]

On 15.12.2023 10:13, Nick Clifton wrote:
>> This patch series adds support in GAS to synthesize CFI for hand-written
>> asm, acronym'd as SCFI.
>>
>> Previous postings:
>>    - RFC patch series (https://sourceware.org/pipermail/binutils/2023-September/129560.html).
>>    - V1 (https://sourceware.org/pipermail/binutils/2023-October/130163.html)
>>    - V2 (https://sourceware.org/pipermail/binutils/2023-October/130210.html)
>>
> The patch series looks great to me.  Series approved - please apply (with a
> small update to the 09 patch as already mentioned).

Please can you hold off committing the x86 part(s) of this, until I got a
chance to look over them again? Furthermore, as expressed before, I'm wary
of these additions going stale the minute the APX patches are committed on
top, if your changes went in first. Despite APX work still being in flight,
I would much prefer if that went in first, and then you re-based your work
on top, such that the new MOV and ALU insns are covered right away.

While this is an unusual situation - new very general purpose insns aren't
introduced frequently -, I'd also like to see more formally addressed the
idea of ongoing support: From the original review I recall that you need
to minimally track insns altering GPRs, in order to avoid silently
generating bad CFI. Remember that I haven't looked at v3 yet, but as long
as that tracking is based on specific insns rather than a generalized
pattern, any ISA addition allowing GPRs to be altered would be at risk of
rendering the CFI generator code stale. Yet people, once they've started
to detect availability of this functionality, may validly expect that
their use of the functionality won't silently break behind their backs. In
this respect, did you consider constraining under what conditions the
generator code may actually come into play (at least for the time being)?

Jan