[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