Using Watcom C to write a kernel

[xor]

Has anyone had any luck using watcom/open watcom to
write a kernel? I am trying to steer away from gcc/djgpp

I am able to output an ELF image with watcom but despite
giving my own startup (crt0) code.. it also adds all this other
DOS dependent startup code which I cant seem to get rid of..

any ideas here?

[mystran]

What's wrong with GCC?

[xor]

gcc itself is fine.. I am using the DOS port of it (djgpp), but to me it has some annoying things.. for one, its sets things up to run in a _non_ flat memory mode (do i blame cwsdpmi here?) l.. base @ 256M or some other silly offset. which means I gotta stuff around allocating descriptors so I can test my code. After this.. I am left with lots of code that wont work properly in my pmode setup (base 0 limit 4g), so porting again to my kernel becomes another chore..

I used watcom for years writing dos programs and it did a damn fine job!

under watcom I could simply declare a pointer to the offset 0xb8000 and it would address it relative to base 0

[Chris Giese]

under watcom I could simply declare a pointer to the offset 0xb8000 and it would address it relative to base 0

I was also impressed by this feature of Watcom C. You can access conventional memory with near pointers _and_ the resulting code works under NTVDM...unlike DJGPP.

I'm not completely sure how DPMI works, but if you set the segment base addresses to zero, then I think the 32-bit code must have fixups in it. This is because the virtual address of a memory block allocated from DPMI is arbitrary.

Anyway, you can stop WLINK from linking in the default DOS code by using the "op nod" option; which is short for "option nodefaultlibs"

[xor]

Quoted:
>Anyway, you can stop WLINK from linking in the default DOS >code by using the "op nod" option; which is short for "option >nodefaultlibs"

Will this cause me to have no access to the libc functions?
ie: string instructions etc?

[Pype.Clicker]

i don't know much about watcom for OSDEv'ing, but you can bypass the DPMI-things of DjGpp by writing your own linker script and asking for a plain binary output (for instance).

[df]

I have used watcom qauite a bit and I love it. I have been through watcom 9/10/11 and now openwatcom 1.1/1.2. 1.3 is coming out soon too btw.

I have done some osdev in watcom a long time ago. it works fine. I had written an LE loader at that point, back then ELF output was flakey at best. now its fine.

you can tell watcom/wlink not to import any default libs and such.
i have some code here i can look to dig out and post later, like th elink script etc.

[xor]

I had to omit main() to fix this because it kept throwing in DOS startup code no matter what I did. I also had to use the -s option with wcc386 to leave out the stack overflow check.. this was causing linking errors such as

__CHK is an undefined reference..

my crt0 code calls kmain()

I have one remaining problem, besides this, everything is starting to look good..

where have _edata and _end gone to? If they're not there how do I zero out the BSS at start? does watcom label them
differently?

The other thing that has me curious (but isnt really a problem), when i use "offset" in my linker settings to specify a linkaddress, the actual entry point of
the code is slightly off (by 100h bytes to be exact) for example, I link it at offset 0x700000
and in e_entry (address field within the elf header containing the address to start the program), its at 0x700100

I am using elf format

any suggestions?

[Solar]

Quoted:
>Anyway, you can stop WLINK from linking in the default DOS >code by using the "op nod" option; which is short for "option >nodefaultlibs"

Will this cause me to have no access to the libc functions?
ie: string instructions etc?

While not immediately obvious when talking about string instructions, you should not use a libc you didn't port or implement yourself.

The **** hits the fan when one of the functions you use has to call malloc() internally, or relies on an errno implementation that requires (in your OS non-existent) runtime support, or any nomber of other issues.

libc is OS-dependent.

[df]

i looked over my stuff. all i did was link without the libs (removed the paths and stuff), no stack checking, and used stack calling conventions..
nothing special. it still output an LE file which I used.