GS base added up with offset does not correspond to gs:offset-CodePudding

When debugging Linux Kernel ran as QEMU guest with GDB I faced the following instruction:

mov    rcx,QWORD PTR gs:0x1fbc0

The question is the rcx register does contain the gs base added up with the value 0x1fbc0. Here is what I figured out in gdb:

#Before execution of the instruction
(gdb) p/x $rcx
$10 = 0x0
(gdb) p/x $gs_base
$11 = 0xffff888237c80000

#Execution of the instruction
(gdb) si
vm_unmapped_area (info=info@entry=0xffffc90000eb7d70) at mm/mmap.c:2002

#Completely unclear value
(gdb) p/x $rcx
$12 = 0xffff888105e79980

My first thought was that GDB reported the GS base incorrectly, but then I got the same from the rdmsr tool

$ sudo rdmsr -p 2 0xc0000101
ffff888237c80000

Making things even more unclear.

Why doesn't gs:0x1fbc0 result in $gs_base 0x1fbc0?

CodePudding user response：

mov with a memory source loads data from the linear address indicated by $gs_base 0x1fbc0, it does not load the linear address itself into the destination.

To address some of your further comments, the qword ptr keywords for a MASM-style dialect indicate a memory access rather than loading an immediate. The rule that all memory accesses are wrapped in brackets [...] and everything else (immediate or register accesses) is not wrapped in brackets is a NASM-ism. In MASM a destination can have keywords {size} ptr or brackets [...] or just specify a variable name to indicate to the assembler to use a memory load. Absent any of those, or by specifying a variable name with an offset keyword prepended, it will encode so as to load an immediate number instead.

Even if your example was an immediate load it would just be mov rcx, 0x1fbc0 without gs as there is no immediate-to-register form instructions that include segment override prefixes with any effect whatsoever. You can technically put a gs prefix in front of such an instruction and it will generally still be decoded fine in practice. However, the gs prefix would serve no purpose then. A disassembler (like gdb's) would hopefully not display the source immediate operand of such an instruction with a gs: prefix.