Re: Configuring for bare hw ia32 PC's

["Jonathan S. Shapiro" <shap at eros-os dot com>]

On Sun, 2008-05-11 at 18:38 -0400, duane ellis wrote:
> Luke A. Guest wrote:
> > Hi,
> >
> > I'm going to be looking into my OS project again and was wondering how
> > to configure newlib. Should I be using i386-elf or i386-pc-elf or
> > something else?
> >
> > I think I'm going to have to do *some* porting work to get newlib to
> > compile for bare PC hw access, i.e. getting dummy I/O code working and
> > also getting screen I/O to go to the BIOS framebuffer.
> >
> > Thanks,
> > Luke.
> >
> >   
> A while back - (April) Jonathan Shapiro was asking about something like 
> this for his Cayotie (spelling?) Operating system

Actually, it's "Coyotos".

I actually went and specialized a configuration for Coyotos. For Luke's
purposes, my recommendation would be to configure for i386-unknown-elf,
and then (if necessary) use an ldscript to put things where he needs
them. Once he knows what addresses he wants things to appear at, it's
easy enough to build a specialized configuration, but until then it's
not really worth the bother.

Luke: for guidance on the ldscript, you are welcome to look at the
Coyotos kernel code. You can browse it through mercurial at

  http://dev.eros-os.com/hg/coyotos/trunk

look in src/arch/i386/kernel/ldscript.S

If he wants an example of multiboot config and setup (which is a serious
pain), he should look in src/arch/i386/BSP/multiboot.

He can see our build process by looking at

  http://dev.eros-os.com/hg/ccs-xenv/trunk

and either poke at the Makefile.xenv/Makefile.target pair or look in
SPECS/Makefile to see how we build RPMs. There are instructions on how
to cross-build the entire tool chain for Coyotos at

  http://www.coyotos.org/download/xenv-by-hand.html

These won't be exact for Luke, but they may provide a starting point.


For newlib itself, the intended "theory of operation" is to define a
short list of required system calls, either by adding a target OS config
section in the newlib tree or by defining them in libgloss. For reasons
having to do with packaging, we elected to do neither. We instead
configured an *empty* libgloss and supplied a libgloss replacement
library from our OS source tree. This allows us to build and package
newlib while retaining the ability to update the system call stubs (e.g.
whenever our IDL emission strategy changes). The end result is that our
libc implementation is split into two archives libc.a and
libc-coyotos.a, which in turn interact with libcoyotos.a. We wrap these
in --begin-group/--end-group on the link line so that they act like a
single archive.

>     (B) it might not, NEWLIB is more of an application standard C library.
>        Not really a "kernel standard c library"

This point is crucial. Our kernel does not use newlib at all, and my
opinion is that it should not do so. If it *does* rely on libc, it
should only rely on the "freestanding" subset of the library. I believe
that our kernel actually does rely on libc for some manifest constants
(things like inttypes.h), but that is about it.

> If you look at the makefile - it builds GCC in 2 stages stage 1 - is 
> just a straight up C compiler, nothing else. No standard library. That 
> should be enough to build your kernel as I describe.

I agree, though I recommend building the kernel with the second round
gcc. Debugging one version of GCC is bad enough. Debugging two versions
is a horror.



shap