[PATCH, V2 2/2] gas: scfi: untraceable control flow should be a hard error
Indu Bhagat
indu.bhagat@oracle.com
Thu Jan 25 19:43:12 GMT 2024
On 1/25/24 05:59, Jan Beulich wrote:
> On 24.01.2024 08:26, Indu Bhagat wrote:
>> --- a/gas/ginsn.c
>> +++ b/gas/ginsn.c
>> @@ -1161,8 +1161,8 @@ ginsn_data_end (const symbolS *label)
>> /* Build the cfg of ginsn(s) of the function. */
>> if (!frchain_now->frch_ginsn_data->gcfg_apt_p)
>> {
>> - as_warn (_("Untraceable control flow for func '%s'; Skipping SCFI"),
>> - S_GET_NAME (func));
>> + as_bad (_("SCFI: untraceable control flow for func '%s'"),
>> + S_GET_NAME (func));
>> goto end;
>> }
>
> This switch is probably fine. My question here is: How come ginsn.c issues
> an SCFI-specific diagnostic? Really most if not all of ginsn_data_end() looks
> to be concerned of only SCFI, when e.g. ginsn_pass_warn_unreachable_code()
> might have value on its own.
>
Thank you for reminding me that - I do remember being of two minds on
keeping the string "Skipping SCFI" originally. On the one hand, the
argument was that "ginsn_pass_warn_unreachable_code() has value on its
own" (like you mention). On the other hand I wondered if users may find
it confusing to see this warning about GAS trying to decipher control
flow for a function and whether this affects the synthesized CFI. So, I
ended up adding "Skipping SCFI"...
I will remove the "SCFI:" string from the message. I think switch to
error relieves me of some of those concerns regarding 'confusing warning
when SCFI is enabled'
Thanks
More information about the Binutils
mailing list