This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Configuring for bare hw ia32 PC's


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
http://www.archeia.com/an-ada95-hello-world-style-kernel.html).

> 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

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
other stuff.

See
http://www.archeia.com/the-ada-microkernel-project-or-tamp-the-plan.html
for more info.

> 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.

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:

* Tasking
* 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
2) Newlib
3) Stage 2 GCC including GNAT, GNAT lib and GNAT tools <- this is the
important part.

Thanks,
Luke.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]