-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
bpo-32962: Fix test_gdb failure in debug build with -mcet -fcf-protection -O0 #9656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
…tion -O0 When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c)
|
@Dormouse759: I modified your PR #6754 to only use the "next" command if Python has been compiled with -mcet -fcf-protection, so it should avoid to break the buildbot. Previously, your change caused an issue on x86 Gentoo Non-Debug with X 3.x and AMD64 Debian PGO 3.x buildbot workers: I kept you as a co-author. |
|
I manually tested on Fedora 28: I also validated that test_gdb fails without the fix ;-) |
Lib/test/test_gdb.py
Outdated
| cflags = sysconfig.get_config_var('CFLAGS') | ||
| flags = cflags.split() | ||
| return (('-mcet' in flags) | ||
| and any(flag.startswith('-fcf-protection') for flag in flags)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about:
return '-mcet' in flags and '-fcf-protection' in flags
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The option takes an optional argument: --fcf-protection=[full|branch|return|none].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this fix tested with these options? I'm afraid that only partial protection might not need the extra 'next'.
Lib/test/test_gdb.py
Outdated
| return (('-mcet' in flags) | ||
| and any(flag.startswith('-fcf-protection') for flag in flags)) | ||
|
|
||
| CET_CF_PROTECTION = cet_cf_protection() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick:
CET - Control-flow enforcement technology
CF - Control-flow
CET_CF_PROTECTION - Control-flow enforcement technology control-flow protection
Pick just one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CET_CF_PROTECTION - Control-flow enforcement technology control-flow protection
Oops :-) I renamed the constant.
test_gdb doesn't need "next" with -fcf-protection=none nor -fcf-protection=return.
I modified my PR to not use "next" for -fcf-protection=none and -fcf-protection=return options. I tested the following configurations: using this shell script: test_gdb now pass with all configurations. |
|
Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7. |
…tion -O0 (pythonGH-9656) When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c) (cherry picked from commit 79d2133) Co-authored-by: Victor Stinner <[email protected]>
|
GH-9770 is a backport of this pull request to the 3.7 branch. |
…tion -O0 (pythonGH-9656) When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c) (cherry picked from commit 79d2133) Co-authored-by: Victor Stinner <[email protected]>
|
GH-9771 is a backport of this pull request to the 3.6 branch. |
…tion -O0 (GH-9656) When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c) (cherry picked from commit 79d2133) Co-authored-by: Victor Stinner <[email protected]>
…tion -O0 (GH-9656) When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c) (cherry picked from commit 79d2133) Co-authored-by: Victor Stinner <[email protected]>
…tion -O0 (GH-9656) (GH-9788) When Python is built with the intel control-flow protection flags, -mcet -fcf-protection, gdb is not able to read the stack without actually jumping inside the function. This means an extra 'next' command is required to make the $pc (program counter) enter the function and make the stack of the function exposed to gdb. test_gdb: get_gdb_repr() now uses the "backtrace 1" command after breakpoint, as in the master branch. Co-Authored-By: Marcel Plch <[email protected]> (cherry picked from commit 9b7c74c) (cherry picked from commit 79d2133)
When Python is built with the intel control-flow protection flags,
-mcet -fcf-protection, gdb is not able to read the stack without
actually jumping inside the function. This means an extra
'next' command is required to make the $pc (program counter)
enter the function and make the stack of the function exposed to gdb.
https://bugs.python.org/issue32962