OSKit and gcc 3.x

[Freanan]

I am really interrested in trying out the OSKit (http://www.cs.utah.edu/flux/oskit) but it requires gcc 2.9 (or something like that - i could post the real version number), while i have gcc 3.5. So when i type make, the result are many compiler errors.

Has anybody else tried to work with the OSKit on the same compiler? Are there special options that could make compiling the OSKit possible? Or do you think it would be reasonable for me to try to fix the errors and make the OSKit gcc 3+ compatible?

[Solar]

gcc 2.95 -> gcc 3.x is a major difference, not only in version number but internals too. There are no compatibility switches I know of.

I'm not sure if its anything of an indicator, but IIRC anyone interested in OSKit on this board so far has given up on the idea pretty quick. You might get no more but a lukewarm response to your efforts. Then again, I might be wrong and you'll be the celebrated hero. Just ask yourself why no-one has done this before.

[distantvoices]

I'd rather use it as kinda reference material.

Quite some nice things are documented/shown in it.

I have no experience in working with it.

Stay safe - have no hankering for a leeeeengthy post

[Freanan]

Maybe the other people who tried it got desinterrested because it would not compile with their gcc version

I thought about experimenting with it, because all my experiments in doing the really lowlevel x86 stuff myself ended in strange errors and problems and only sometimes people could help me.
Thus, as i read of a library that offers various levels of abstraction (from lidt() style functions over init_interrupts() like stuff to do_everything() styled functions) i got rather fascinated with the idea and wanted to experiment with it at least...

Maybe they will release a gcc 3 compatible version in the future
or just a precompiled version that can be linked into other code..

[Pype.Clicker]

i'd rather try to use the "OSLib" instead (it should be in the QuickLinkz or on the links page of the FAQ).

[Solar]

To be honest, I never got further than chapter 1.2.1 of the intro (boldface is mine):

1.2.1 Interfaces

The OSKit?s interfaces are a set of clean, object-oriented interfaces specified in the framework of the Component Object Model (COM), described in Chapter 4.

COM? To interconnect kernel components?

Ugh. Arg. Erm. No.

[mystran]

It sounds evil, but COM is actually not as bad at it first sounds like. It's still a horribly bloated approach to something like kernel interfaces, but at least they don't use something like CORBA.

But yeah. That's the same reason I never really considered using OSKit for anything.

[Freanan]

I will have a look at OSLib, thanks!

About the COM thing: I read a bit more of the writings on the OSKit and it turned out, that the object oriented stuff is just the top-level of the OSKit, which has neither to be compiled in, nor to be used.
It is intended for people who do not want to write an OS but have to work on bare metal - for example for coding a server that runs without an os, or for porting strange outlandish scripting languages like Scheme to the lowlevel (strange idea, but i recall that some people in here were interrested in that actually).
There is also a procedural interface to things on a much lower level.

[Freanan]

I tried to compile the OSLib but it seems to have the same compatibility problems - the website states that it was only tested on gcc 2.

Still the OSLIb is smaller and thus the errors are concentrated in one small function.
I would have fixed them myself but it is in inline assembly, which i can't really decipher. It would be great if someone could post some gcc 3 compatible semantic equivalent of it:

Code: Select all

/*
 * find the first occurrence of byte 'c', or 1 past the area if none
 */
#define __HAVE_ARCH_MEMSCAN
extern inline void * memscan(void * addr, int c, size_t size)
{
   if (!size)
      return addr;
   __asm__("cld
      repnz; scasb
      jnz 1f
      dec %%edi
1:      "
      : "=D" (addr), "=c" (size)
      : "0" (addr), "1" (size), "a" (c));
   return addr;
}

Those are the error messages:

Code: Select all

make -C xlib all
make[1]: Entering directory `/home/freanan/dloads/oslib/xlib'
gcc -Wall -O -finline-functions -fno-builtin -nostdinc -D__LINUX__ -I.. -D__VIRCSW__ -D__NOH4__ -DPROFILE  -c 
[b]
In file included from x1.c:31:
../ll/i386/mem.h:307:17: missing terminating " character
In file included from x1.c:31:
../ll/i386/mem.h: In function `memscan':
../ll/i386/mem.h:308: error: syntax error before "repnz"
../ll/i386/mem.h:309: error: `scasb' undeclared (first use in this function)
../ll/i386/mem.h:309: error: (Each undeclared identifier is reported only once
../ll/i386/mem.h:309: error: for each function it appears in.)
../ll/i386/mem.h:309:21: invalid suffix "f" on integer constant
../ll/i386/mem.h:311:17: missing terminating " character[/b]
../ll/i386/hw-instr.h: In function `restore_fpu':
../ll/i386/hw-instr.h:126: warning: use of memory input without lvalue in asm operand 0 is deprecated
x1.c: At top level:
x1.c:33: warning: `FileName' defined but not used
make[1]: *** [x1.o] Error 1
make[1]: Leaving directory `/home/freanan/dloads/oslib/xlib'
make: *** [all] Error 2

[proxy]

that function seems like a "memchr" with slightly different implementation (returns 1 past end instead of null on not found)

but anyway, why do that in asm, when it can be done very simply in C..for example:

Code: Select all

void *memchr(const void *s, int c, size_t n) {
   const unsigned char *s_ptr = (const unsigned char *)s;
   void *ret = 0;
   assert(s != 0);
   
   while(n--) {
      if(*s_ptr == (const unsigned char)(c & 0xff)) {
         ret = (void *)s_ptr;
         break;
      }
      ++s_ptr;
   }

   return ret;
}

it isn't exactly difficult to come up with such functions

proxy

[AR]

More specifically, GCC is having a problem with the fact that each line isn't closed in quotes, to fix it try:

Code: Select all

extern inline void * memscan(void * addr, int c, size_t size)
{
   if (!size)
      return addr;
   __asm__("cld\n\t"
      "repnz; scasb\n\t"
      "jnz 1f\n\t"
      "dec %%edi\n\t"
      "1:\n\t"
      : "=D" (addr), "=c" (size)
      : "0" (addr), "1" (size), "a" (c));
   return addr;
}

[Freanan]

Thanks to both of you!
I will try it out as soon as i am at home again.
(As well as the OSLib itsself )

Maybe you would like to send the gcc-3 compatibilized code to the OSLib people?

[Solar]

Being maintainer of some legacy code myself, I would recommend sending a diff output instead of the whole file. That actually makes it easier for the maintainers to merge it with whatever work they're currently doing.

If someone sends me a whole file, making a diff against what I have in the repository is the first thing I do.

[Freanan]

Thanks to your help i have managed to compile the oslib by now.
I also read through its documenatation and think it is pretty cool and maybe more suited to my needs than the oskit anyway, if everything works as it should .

But there are more problems:
I tried to install a kernel from ./examples and grub on a floppy image (using the loopback device, connecting it to the image file, creating ext2 fs on it, packing the grub stuff and the kernel file to it, running grub to properly install it on the 'floppy') and booting it with bochs.
The result was the following output (and a hanging bochs):

Code: Select all

[Multiboot-elf, <0x220000:0x82b2:0x997a>,

Did i do anything wrong? Or is the code maybe incompatible with newer gcc even on a semantic level so that the example kernel won't work even though it compiled? I would be thankfull for any ideas or help...

[Solar]

The output states that GRUB identified your kernel as Multiboot-compatible and tried to load it.

What happened then? Welcome to the world of kernel debugging.