To clarify, by "make the switch" I mean replacing tr with tsl. Also,
thanks again for another very high quality bug report.
Gabe
On 04/27/11 12:56, Gabe Black wrote:
> There's a good chance the implementation was copied from LTR and not
> completely updated. Please go ahead and make the switch, and if it works
> I'm willing to say that's what the problem is. I'll look it over once
> more carefully if that works and we're going to commit it.
>
> Gabe
>
> On 04/27/11 04:47, Tim Harris (RESEARCH) wrote:
>> 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
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
