[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