diff options
| author | Andrew Burgess <aburgess@redhat.com> | 2024-03-23 16:17:36 +0000 |
|---|---|---|
| committer | Andrew Burgess <aburgess@redhat.com> | 2024-05-07 17:05:10 +0100 |
| commit | 868883583e7520ff1bd99fcb224d2b33a990edff (patch) | |
| tree | f6e9f89cb45d387dff2eb2620d07125a3d460714 /gas/testsuite | |
| parent | 0c58b372e07fe81d23e4fcf6d6cfee8394e8bce5 (diff) | |
| download | gdb-868883583e7520ff1bd99fcb224d2b33a990edff.zip gdb-868883583e7520ff1bd99fcb224d2b33a990edff.tar.gz gdb-868883583e7520ff1bd99fcb224d2b33a990edff.tar.bz2 | |
gdb/arch: assert that X86_XSTATE_MPX is not set for x32
While rebasing this series[1] past this commit:
commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a
Date: Wed Mar 20 04:13:18 2024 -0700
gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32
I worried that there could be other paths that might result in an xcr0
value which has X86_XSTATE_MPX set in x32 mode. As everyone
eventually calls amd64_create_target_description to build their target
description, I figured we could assert in here that if X86_XSTATE_MPX
is set then we should not be an x32 target, this will uncover any
other bugs in this area.
I'm not currently able to build/run any x32 binaries, so I have no way
to test this, but the author of commit 4bb20a6244b7091 did test this
series with that assert in place and didn't see any problems.
[1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Diffstat (limited to 'gas/testsuite')
0 files changed, 0 insertions, 0 deletions