libgloss and newlib

[Doug Evans]

   From: Mark Pulver <mpulver@research.canon.com.au>
   Date: Tue, 28 Sep 1999 11:12:06 +1000 (EST)

   I'm trying to build an embedded system using a GNU  tool chain
   on a StrongArm board (Brutus).  I have no problem running under gdb
   as IO is handled via SWI to the Angel monitor.

   Reading the "porting" info pages in newlib, mentions that libgloss
   should be used to embed the system.  I have code I can used for crt0.o
   and inbyte() and outbyte(), but how do I hook them into the
   existing newlib (libc.a) code.  Do I put them into my owm libgloss.a?
   How does the linker choose the my crt0.o not the one in libc.a? Is
   where a "configure" flag I require to rebuild newlib to be used with
   libgloss?

   Ideally, I would like stdin/stdout to use a serial port, and stderr
   to write to the LCD.  I have code that does this, I just don't know
   how to use it with newlib.

I haven't seen a response so I'll take a crack at it.

For the ARM port, what one expects to live in libgloss actually lives
in newlib.  This is only because the code hasn't been moved to libgloss
(which can be tricky if only because of what existing people are doing
with it - one doesn't know so one has to be extra careful).

See newlib/libc/sys/arm/*.
What you might want to do is just disable the building of that directory.
Do this by editing newlib/configure.in:

   arm-*-*)
-        sys_dir=arm
+        #sys_dir=arm
         ;;

I haven't tried it but methinks that should "just work".
Then take what's there and munge it into your own version of what you want.

Ideally you wouldn't have to do this and maybe you don't.
The catch is playing with gcc's -nostartfiles, -nodefaultlibs, -nostdlib
to find the right combination (if any) that disables the things you don't
want.

e.g.  maybe

gcc -nostartfiles my-crt0.o foo.o bar.o my-syscall-replacements.o

will do what you want.
What you'd need is to have my-syscall-replacements.o supply the relevant
parts of what newlib/libc/sys/arm/* supplies.  It's kind of hacky though.

As for inbyte/outbyte, ports don't always use them.  It's read(),write()
that would ultimately call them but if you provide your own read/write
then you can do things however you want.

In newlib/libc/sys/arm/syscalls.c, the _read(),_write() routines
just call into the Angel monitor.

Some ports use read(),write() some use _read(),_write().
[This has nothing to do with whether the compiler prepends "_" to
symbols, btw.]