Hi,
I'm trying to debug some user-mode software that is using the LDT in ways which
AFAIK are correct on x86-64, but which are provoking a GPF when running in FS
mode on M5 (either the tip, or some older trees I've been using).
This is running on the Barrelfish OS, so the way the software's using the LDT
may well be different from Linux or other cases that have been used in the past.
The GPF happens at a "mov %ax, %fs" instruction. %ax is 7 => RPL=3, and use
the first entry in the LDT. It looks like the LDT is 0, and the GPF occurs
when accessing address 0 to load the first entry. The program previously
initializes the LDT via an LLDT instruction in a system call, but it looks like
the value is not being written correctly.
Looking at LLDT_R in src/arch/x86/isa/insts/system/segmentation.py:
def macroop LLDT_R
{
.serializing
chks reg, t0, InGDTCheck, flags=(EZF,)
br label("end"), flags=(CEZF,)
limm t4, 0, dataSize=8
srli t4, reg, 3, dataSize=2
ldst t1, tsg, [8, t4, t0], dataSize=8
ld t2, tsg, [8, t4, t0], 8, dataSize=8
chks reg, t1, LDTCheck
wrdh t3, t1, t2
wrdl tr, t1, reg
wrbase tr, t3, dataSize=8
end:
fault "NoFault"
};
Is there a bug with the final two stores to TR? I'd been expecting the code to
be setting the base and limit of TSL somewhere (by analogy with TSG in LGDT).
I'm not sure I understand x86 segmentation to be very confident of writing a
fix - e.g., if it's just TR->TSL, or if there's something more subtle needed
(or indeed if I'm completely wrong here!).
Thanks,
Tim
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
