On Tue, Jan 12, 2021 at 3:39 AM Metzger, Markus T <markus.t.metz...@intel.com> wrote: > > > The GDB behavior looks to be different between the two cases -- with vs > > without gdb server, when I checked the GS/GSBASE values on the ptrace front. > > 64-bit GDB doesn't support FSGSBASE for 32-bit inferiors and it looks like > gdbserver > might not support FSGSBASE, at all. > > I had added support for the former as part of the tests I wrote about a year > ago [1] > but never submitted the patch. Was the discussion ever concluded? > > The general behavior should be that GDB reads a regset, overwrites the > registers it > knows about, and writes it back again to preserve the original values of > registers it > doesn't know about. > > When I log the values that are read and written for FSGSBASE, however, it > looks like > ptrace is returning a non-zero GS_BASE on a read and gdbserver is writing > zero on > the next write.
I instrumented the kernel, and I see: [ 26.990644] getreg: gs_base = 0xf7f8e000 [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000 [ 26.993117] PTRACE_SETREGS [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0x0 [ 26.995134] putreg: write GS=0x63; old GSBASE=0x0 [ 26.996235] PTRACE_SETREGS done That's gdbserver reading GS and GSBASE and then telling the kernel to set GS to the same value and GSBASE to 0. I can come up with horrible kernel hacks to try to work around this, but gdbserver is really giving the kernel bad instructions here. --Andy
