Mail Archives: djgpp/2006/03/01/21:16:56
"DJ Delorie" <dj AT delorie DOT com> wrote in message
news:200603011425 DOT k21EPHCE005449 AT envy DOT delorie DOT com...
> "Florian Liebig" <FlorianLiebigEMD AT compuserve DOT de> wrote in message
news:4404EB6F DOT D050DB39 AT compuserve DOT de...
>> hi guys at comp.os.msdos.djgpp.
>> i've got a serious problem now.
>> i'm using djgpp gnu gcc package 2.7.2 and all i want to use it for is
>> developing a kernel in high level language. the compiled 32bit kernel
>> shall be used by an experimental os written by myself. but there's my
>> problem : the output of gcc.exe/ld.exe always need to link in some
>> library functions of libgpp/ libc etc., what i do not understand,
>> because the code that i wrote doesn't makes the use any of the specific
>> gnu libraries.
>> the next problem is ld.exe's behaviour to link in the stub program, that
>> makes it executable in msdos env's.
>> is there any way to link the .o files with ld.exe to a plain 32bit
>> prot.-mode binary image ??
>> please tell me how to go on creating a plain code image to further
>> proceed on.
>
> You want a cross compiler, not a native compiler. You probably want
> to build an i386-elf compiler that runs on djgpp.
>
> If you really want to use djgpp's native compiler, you'll probably
> want to run the linker yourself so you know *exactly* what you're
> including in your image.
No, he doesn't need a cross compiler.
> all i want to use it for is developing a kernel in high level language
I'm already doing that with both DJGPP and OW. I'm running a Ring 0 OS
written in DJGPP and OW without using a cross-compiler for either one. The
disadvantage is that it can only be started from RM DOS (so far). It won't
be startable with GRUB, etc...(at least not immediately, this can be added
later on in development)
> the next problem is ld.exe's behaviour to link in the stub program, that
> makes it executable in msdos env's.
> is there any way to link the .o files with ld.exe to a plain 32bit
> prot.-mode binary image ??
No. But, there is a way around it. I'm not going to post the code for my
OS, but I'll explain to you the method for DJGPP to bypass this.
When you call exit() in your program, int 0x21, ah=4c "DPMI Unload" is
called in PM. Then the DPMI host cleans up memory and returns to RM. When
in RM, int 0x21, ah=4c "DOS Exit" is called by DOS to clean up after your
program exits.
Now, let's setup a RM int 0x21 routine which prevents int 0x21, ah=4c from
being called, say from a TSR which we run first. What happens when we run
our os.exe after the TSR and call exit()? We've exited our PM program but
our int 0x21 RM routine has complete control over the computer. Can we
restart our PM program where it left off? If we are using a non-paging DPMI
host, we can. (i.e., stubedit os.exe change CWSDPMI.EXE to PMODETSR.EXE) A
paging DPMI host like CWSDPMI reorganizes pages memory (i.e., scrambles).
If we do restart our program, we'll have no DPMI host, no PM interrupts,
etc... And, we can then write our OS using only the C compiler, some CISC
instructions with _asm(), and perhaps string or character functions.
So, what do we need to do to restart our application? For DJGPP, before the
PM application calls exit, we need to save some information that can be
accessed by the RM int 0x21, routine:
0) push the callee-savee registers esi,edi,ebx onto the PM stack (restored
later)
1) the base address of _my_cs()
2) the stack frame pointer (esp)
3) the prior stack frame pointer (ebp)
4) an address to set the intruction pointer to for reentry
Then, the RM int 0x21 routine does the following:
1) disable interrupts
2) creates and sets up a minimal GDT with three selectors
a) selector for PM application code using the saved base address
b) selector for PM application data using the saved base address
c) linear selector for interrupt routine code
3) set the CR0 PE bit, and switch to PM, do other Intel/AMD recommended
stuff
4) restore ESP,EBP
5) setup DS,ES,FS,GS
6) far jump to reentry address (sets CS)
Now, we've restarted our PM application:
1) restore push the callee-savee registers esi,edi,ebx
2) reset __djgpp_ds_alias, __go32_info_block+26 (_dos_ds), __djgpp_dos_sel
3) Yeah! Our program is running again.
4) create better GDT in C
5) create IDT in C
6) create ISR in C with _asm() wrappers
7) setup keyboard & mouse, enable interrupts, etc..
Now we're running in PM with no DPMI host. At this point everything can be
done in C except:
1) special instructions lgdt,lidt,
2) assembly wrappers for interrupt service routines
And those can be done with the C _asm() directive. Remember, you can't use
CWSDPMI to do this...
Rod Pemberton
- Raw text -