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

Reply via email to