diff options
author | Jan Beulich <jbeulich@suse.com> | 2022-03-23 12:28:53 +0100 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2022-03-23 12:28:53 +0100 |
commit | 4faaa10f3fabb345aca006ed67a8be97dc924e9c (patch) | |
tree | 3168a6566e87a385ec787f2826b4b801a39b0dd0 /libtool.m4 | |
parent | 131a355fbca43e4e4ab2a3bfcbc17e0836fa8dc2 (diff) | |
download | gdb-4faaa10f3fabb345aca006ed67a8be97dc924e9c.zip gdb-4faaa10f3fabb345aca006ed67a8be97dc924e9c.tar.gz gdb-4faaa10f3fabb345aca006ed67a8be97dc924e9c.tar.bz2 |
x86: don't attempt to resolve equates and alike from i386_parse_name()
PR gas/28977
Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
i386_parse_name() to call parse_register(). This being a hook from the
expression parser, it shouldn't be resolving e.g. equated symbols.
That's relevant only for all other callers of parse_register().
To compensate, in Intel syntax mode check_register() needs calling;
perhaps not doing so was an oversight right when the function was
introduced. This is necessary in particular to force EVEX encoding when
VRex registers are used (but of course also to reject bad uses of
registers, i.e. fully matching what parse_register() needs it for).
Diffstat (limited to 'libtool.m4')
0 files changed, 0 insertions, 0 deletions