aboutsummaryrefslogtreecommitdiff
path: root/libtool.m4
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2022-03-23 12:28:53 +0100
committerJan Beulich <jbeulich@suse.com>2022-03-23 12:28:53 +0100
commit4faaa10f3fabb345aca006ed67a8be97dc924e9c (patch)
tree3168a6566e87a385ec787f2826b4b801a39b0dd0 /libtool.m4
parent131a355fbca43e4e4ab2a3bfcbc17e0836fa8dc2 (diff)
downloadgdb-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