aboutsummaryrefslogtreecommitdiff
path: root/zlib/qnx
diff options
context:
space:
mode:
authorIndu Bhagat <indu.bhagat@oracle.com>2024-08-01 10:07:07 -0700
committerIndu Bhagat <indu.bhagat@oracle.com>2024-08-01 10:07:07 -0700
commitd56083b5047b8e7cc9eda2f867bd2b75724920a1 (patch)
tree4127e5e370ad25d6de0306e3d90ba9b12d9741d1 /zlib/qnx
parent94223333026f06dc5d78266dd9b6082544641f07 (diff)
downloadgdb-d56083b5047b8e7cc9eda2f867bd2b75724920a1.zip
gdb-d56083b5047b8e7cc9eda2f867bd2b75724920a1.tar.gz
gdb-d56083b5047b8e7cc9eda2f867bd2b75724920a1.tar.bz2
gas: x86: ginsn: handle previously missed indirect call and jmp ops
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.
Diffstat (limited to 'zlib/qnx')
0 files changed, 0 insertions, 0 deletions