aboutsummaryrefslogtreecommitdiff
path: root/ld
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2018-05-03 17:46:14 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2018-05-08 18:03:46 +0100
commit8ee22052f690c007556b97eed59f49350ece5ca9 (patch)
tree4e777bd6bcd84d061f8ca31b5425d000d866ce3b /ld
parent886d542809fd73fba55ba72da1bd64ba50164222 (diff)
downloadgdb-8ee22052f690c007556b97eed59f49350ece5ca9.zip
gdb-8ee22052f690c007556b97eed59f49350ece5ca9.tar.gz
gdb-8ee22052f690c007556b97eed59f49350ece5ca9.tar.bz2
gdb/x86: Handle kernels using compact xsave format
For GNU/Linux on x86-64, if the target is using the xsave format for passing the floating-point information from the inferior then there currently exists a bug relating to the x87 control registers, and the mxcsr register. The xsave format allows different floating-point features to be lazily enabled, a bit in the xsave format tells GDB which floating-point features have been enabled, and which have not. Currently in GDB, when reading the floating point state, we check the xsave bit flags, if the feature is enabled then we read the feature from the xsave buffer, and if the feature is not enabled, then we supply the default value from within GDB. Within GDB, when writing the floating point state, we first fetch the xsave state from the target and then, for any feature that is not yet enabled, we write the default values into the xsave buffer. Next we compare the regcache value with the value in the xsave buffer, and, if the value has changed we update the value in the xsave buffer, and mark the feature enabled in the xsave bit flags. The problem then, is that the x87 control registers were not following this pattern. We assumed that these registers were always written out by the kernel, and we always wrote them out to the xsave buffer (but didn't enabled the feature). The result of this is that if the kernel had not yet enabled the x87 feature then within GDB we would see random values for the x87 floating point control registers, and if the user tried to modify one of these register, that modification would be lost. Finally, the mxcsr register was also broken in the same way as the x87 control registers. The added complexity with this case is that the mxcsr register is part of both the avx and sse floating point feature set. When reading or writing this register we need to check that at least one of these features is enabled. This bug was present in native GDB, and within gdbserver. Both are fixed with this commit. gdb/ChangeLog: * common/x86-xstate.h (I387_FCTRL_INIT_VAL): New constant. (I387_MXCSR_INIT_VAL): New constant. * amd64-tdep.c (amd64_supply_xsave): Only read state from xsave buffer if it was supplied by the inferior. * i387-tdep.c (i387_supply_fsave): Use I387_MXCSR_INIT_VAL. (i387_xsave_get_clear_bv): New function. (i387_supply_xsave): Only read x87 control registers from the xsave buffer if the feature is enabled, and the state will have been written, otherwise, provide a suitable default. (i387_collect_xsave): Pre-clear all registers in xsave buffer, including x87 control registers. Update control registers if they have changed from the default value, and mark features as enabled as required. * i387-tdep.h (i387_xsave_get_clear_bv): Declare. gdb/gdbserver/ChangeLog: * i387-fp.c (i387_cache_to_xsave): Only write x87 control registers to the cache if their values have changed. (i387_xsave_to_cache): Provide default values for x87 control registers when these features are available, but disabled. * regcache.c (supply_register_by_name_zeroed): New function. * regcache.h (supply_register_by_name_zeroed): Declare new function. gdb/testsuite/ChangeLog: * gdb.arch/amd64-init-x87-values.S: New file. * gdb.arch/amd64-init-x87-values.exp: New file.
Diffstat (limited to 'ld')
0 files changed, 0 insertions, 0 deletions