where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: opexoc on 15 Aug 2007 17:45 On 14 Sie, 23:24, James Harris <james.harri...(a)googlemail.com> wrote: > On Aug 14, 9:49 pm, ope...(a)gmail.com wrote: > > > On 14 Sie, 21:54, Frank Kotler <fbkot...(a)verizon.net> wrote: > > > > Google for "a20 - a pain from the past"... I'll save you the trouble: > > > >http://www.win.tue.nl/~aeb/linux/kbd/A20.html > > > Thanks for this link but I don't find there explanation why A20 line > > is responsible for access odd megabytes. > > It's not written to answer your question specifically but does this > help: > > http://aodfaq.wikispaces.com/#tochome28 Thanks. Wiktor
From: opexoc on 15 Aug 2007 19:03 On 15 Sie, 16:12, "Wolfgang Kern" <nowh...(a)never.at> wrote: > > After the jump of course, because CS is loaded by the FAR jump > and exactly there occure the mode-transition. > > If the distance of clear_pipe is beyond 16 bit limits, or if the > clear_pipe is already defined as a 32-bit label, then you should > either have the [bits 32] before the label, or manually extend > the jump by an '66h'-prefix and the two more bytes in the offset. > > Not sure if your tool will handle this by itself, > the produced code should then look like: > > 66 EA xx xx xx xx 08 00 JMPF 0008: xxxxxxxxh > [BITS 32] after the jump I want to be sure about that: Can I exploit 32 bit address in 16 bit mode? ( I want to be really sure. ) Wiktor
From: Wolfgang Kern on 16 Aug 2007 04:05 Wiktor (opexoc) asked: >> After the jump of course, because CS is loaded by the FAR jump >> and exactly there occure the mode-transition. >> If the distance of clear_pipe is beyond 16 bit limits, or if the >> clear_pipe is already defined as a 32-bit label, then you should >> either have the [bits 32] before the label, or manually extend >> the jump by an '66h'-prefix and the two more bytes in the offset. >> > > Not sure if your tool will handle this by itself, > > the produced code should then look like: > > > > 66 EA xx xx xx xx 08 00 JMPF 0008: xxxxxxxxh > > [BITS 32] after the jump > I want to be sure about that: Can I exploit 32 bit address in 16 bit > mode? ( I want to be really sure. ) This is the reason why 66h and 67h overrides exists at all :) Yes you can with BIG-REAL mode, but be aware that any IRQ-routine will alter CS and then crash for sure. So Big Real is of limited use because IRQs must be disabled during it. And of course you can use the 66/67 overrides while in PM16 (if your tool is unable to figure it out by its own) to access data in 32-bit 'segments' ie: assume this GDT entries: 00h 08 16-bit stack (at 1.MB) 10 16-bit code (at 1.MB) 18 32-bit code (unlimited flat) 20 32-bit stack and data (flat) .... and what could be done with it: ;bits16 yet 6a 20 push +20h 1f pop ds 66 67 a1 10 20 30 D8 mov eax,dword[D8302010h] I use things like this very rare, as I need the opposite more often, ie: calling true Realmode BIOS service from within PM32. This needs a full back and forward switch (VM86 is just too slow for me). __ wolfgang
From: Wolfgang Kern on 16 Aug 2007 04:24 James Harris asked: ... > If the CPU were to take an interrupt between > mov cr0,eax > and > jmp 08h:clear_pipe > could it return from the interrupt already in Protected mode? In other > words, does the mov cr0,eax actually set protected mode and the > following jump just clear the prefetch queue. No, it probably wont even enter the correct IRQ-routine because the IRQ itself loads CS:EIP. > Or does the CPU remain in real mode until a far jump? Yes "until CS become altered", ..the playground for BigReal. > If the former is the case then should interrupts be disabled over the > transition to protected mode? The former is the case. So better disable IRQS during RM/PM switches/LGDT/LIDT/LLDT/.. :) __ wolfgang
From: Alexei A. Frounze on 16 Aug 2007 05:28
On Aug 16, 1:24 am, "Wolfgang Kern" <nowh...(a)never.at> wrote: > James Harris asked: > ... > > > If the CPU were to take an interrupt between > > mov cr0,eax > > and > > jmp 08h:clear_pipe > > could it return from the interrupt already in Protected mode? In other > > words, does the mov cr0,eax actually set protected mode and the > > following jump just clear the prefetch queue. > > No, it probably wont even enter the correct IRQ-routine > because the IRQ itself loads CS:EIP. It most likely will enter the correct ISR (given properly set up GDT, IDT and the interrupt controller). But there will be #GP on IRET because of popping invalid CS from the stack. > > Or does the CPU remain in real mode until a far jump? > > Yes "until CS become altered", ..the playground for BigReal. No, it does not remain in real mode until a far jump. The mode is already not real after PE is set to 1. I can agree to call this a transitive mode or gray mode or whatever, but it's definitely neither properly functioning real mode nor properly setup protected mode (potentially not yet properly functioning either). Alex |