[PATCH,V2] gas: x86: ginsn: handle previously missed indirect call and jmp ops

Jan Beulich jbeulich@suse.com
Thu Aug 1 09:18:21 GMT 2024


On 01.08.2024 09:57, Indu Bhagat wrote:
> Some flavors of indirect call and jmp instructions were not being
> handled earlier, leading to a GAS error (#1):
>   (#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI"
> 
> Not handling jmp/call (direct or indirect) ops is an error (as shown
> above) because SCFI needs an accurate CFG to synthesize CFI correctly.
> Recall that the presence of indirect jmp/call, however, does make the
> CFG ineligible for SCFI. In other words, generating the ginsns for them
> now, will eventually cause SCFI to bail out later with an error (#2)
> anyway:
>   (#2) "Error: untraceable control flow for func 'XXX'"
> 
> The first error (#1) gives the impression of missing functionality in
> GAS.  So, it seems cleaner to synthesize a GINSN_TYPE_JUMP /
> GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with
> the error as expected.
> 
> The handling for these indirect jmp/call instructions is similar, so
> reuse the code by carving out a function for the same.
> 
> Adjust the testcase to include the now handled jmp/call instructions as
> well.
> 
> gas/
> 	* config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New
> 	function.
> 	(x86_ginsn_new): Refactor out functionality to above.
> 
> gas/testsuite/
> 	* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output.
> 	* gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of
> 	jmp/call opcodes.

Okay.

Jan


More information about the Binutils mailing list