Configuring for bare hw ia32 PC's
Luke A. Guest
Mon May 12 17:08:00 GMT 2008
On Mon, 2008-05-12 at 11:25 -0400, Jonathan S. Shapiro wrote:
> 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,
Ok. Will this also build the file functions? I've tried before, a while
back, but I think I used i386-elf and it didn't provide this as the Ada
runtime was wanting dirent.h, IIRC.
> 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.
Yeah, I've created (more like copied and hacked up) an ldscript for a
test kernel (see
> Luke: for guidance on the ldscript, you are welcome to look at the
> Coyotos kernel code. You can browse it through mercurial at
> look in src/arch/i386/kernel/ldscript.S
Will do, just to see :D
> If he wants an example of multiboot config and setup (which is a serious
> pain), he should look in src/arch/i386/BSP/multiboot.
Again, I've done this before, but will be looking at doing this for
multiple architectures, so GRUB2 for ia32 and whatever is available for
for more info.
> He can see our build process by looking at
> 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
> These won't be exact for Luke, but they may provide a starting point.
K, it all helps :D
> 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
I think this is the way I need to go. I basically need to get GNAT built
*with* a runtime library, this runtime will be configured to cause
compilation errors when using things I don't want to use in the kernel,
which will most likely be:
* Exceptions - I'm still not sure if I would use them inside the kernel.
* Memory management - Not too sure about this either, I will most
probably be keeping the memory management inside the kernel for now, as
this is a first attempt at a microkernel :D
* I/O - I can implement my own framebuffer based I/O for sending
debugging info to the screen.
I still need the runtime for other things, like being able to use the
standard packages for strings, enumerations, etc.
> > 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.
Well, the intention is to get:
1) Stage 1 GCC
3) Stage 2 GCC including GNAT, GNAT lib and GNAT tools <- this is the
More information about the Newlib