This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Configuring for bare hw ia32 PC's
On Mon, 2008-05-12 at 16:57 +0100, Luke A. Guest wrote:
> 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.
It will not. Coyotos doesn't have a file system at the libc level.
Eventually, when we specify the IDL for a stream interface, the
low-level versions of those functions (read, write, and friends) will
end up in libcoyotos.a. For our purposes, we want those to be built
completely independent of newlib.
I'm not sure about status of dirent.h in newlib, but I seem to recall a
discussion about that happening not very long ago. dirent.h is not part
of the C standard library specification, so the decision to provide that
(or not) is part of the target-specific arrangements in newlib (or if it
isn't, it should be).
> > 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.
Just FYI, we subsequently abandoned the GRUB module model to load the
application-level system image. On deeply embedded platforms, there
simply isn't any good place to update the module line in the grub
config, and it's a pain in the butt to push two files to flash. What we
are now doing instead is using an ldscript trick to simply link-edit the
system image directly into the kernel module.
During compile, we link the kernel two ways: once normally to check for
unresolved symbols, and the second time using -r, which is the one we
actually use (but note that this has no unresolved symbols). Later, we
will use a linker trick to link the app-level system image directly into
the binary. See src/build/coymerge.
We have found this to be much more convenient than grub, not least
because the grub memory management interface utterly sucks.
> > 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...
Just FYI, this took some thuggery on the gcc link line handling, and at
this point you'll want to set up your own configuration. If you look in
our ccs-xenv tree under SOURCES, any file beginning with capos-xxx is
the patch file that provides patches specific to Coyotos or Capros.
Those will include our link line hacks and everything you need to patch
in a specialized target.
Note that the i386 target is currently missing the
--begin-group/--end-group flags in the link line, which is known bug
that will be fixed next time I update those tools.
>
> > > 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.
Yes. But having done that, don't try to use stage1 GCC to build your
kernel. Use stage2 GCC for everything, if only to reduce the number of
variants of tools that can hurt you.