On 12/04/13 19:47, Jordan Justen wrote: > On Wed, Dec 4, 2013 at 10:05 AM, Laszlo Ersek <ler...@redhat.com> wrote: >> And, now I have some idea why it happens. I hacked PlatformPei and >> S3Resume2Pei to read the CS and log it. (Of course without seeing the >> actual GDT entries that these values point to we can't say much, but we >> can't say something.) > > You could use AsmReadGdtr to dump the GDT in a debug message. Or, > possibly add a CpuDeadLoop call, and look at the GDT with the QEMU > monitor. > >> I also added a small count-down loop in gcc inline >> assembly that uses LRETQ for the iteration -- I load CS to RAX, push >> RAX, compute the RIP in RAX and push that too, then LRETQ. >> >> In PlatformPei, after cold boot *or* resume, Cs=0x18, and the loop with >> LRETQ works. >> >> In S3Resume2Pei, after resume, Cs=0x0418, and the loop with LRETQ still >> works (IOW whatever GDT we use, it has a good entry for the 0x0418 >> selector). But, there's this section in S3ResumeExecuteBootScript(): > > This seems suspicious. I don't think either the firmware or OS will > define a selector higher than ~0x40.
I'm an idiot. I messed up the format string in a hurry. 0x%04Lx vs 0x04%Lx You'll note that if the Lx directive produces two characters, the output has the same width. Please someone take these sharp tools from me, I clearly can't master them. :-/ Laszlo ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
