diff options
author | Indu Bhagat <indu.bhagat@oracle.com> | 2024-08-01 10:07:07 -0700 |
---|---|---|
committer | Indu Bhagat <indu.bhagat@oracle.com> | 2024-08-01 10:07:07 -0700 |
commit | d56083b5047b8e7cc9eda2f867bd2b75724920a1 (patch) | |
tree | 4127e5e370ad25d6de0306e3d90ba9b12d9741d1 /zlib/qnx | |
parent | 94223333026f06dc5d78266dd9b6082544641f07 (diff) | |
download | gdb-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