Stdio redirection?

[Kai Ruottu]

Noah Aklilu wrote:
> 
> I don't think you really have to mess with libgloss directories until
> you have something definite in the way of libraries setup.  Here are
> snippets of my makefile and linker script for a 68306 system I was
> working on recently:

 The 'h8300-hms' is a 'fully defined target', just like 'i586-linux' is.
Ie. the produced C-library includes all the necessary functions for getting
the first 'Hello World' compiled and linked just by writing:

   h8300-hms-gcc -o hello hello.c

So the 'H8/300 with the HMS-monitor (or what the HMS then was) could be called
a 'system' target like Linux.

 But the 'm68k-coff/elf' targets don't tell anything about the real target,
only about the used object format. When trying the equivalent:

   m68k-coff-gcc -o hello hello.c

all kind of undefined symbols (_write, _open, _sbrk) will be seen. Then we
will see 'funny' ;-) questions from newbies why these functions are missing...
Of course every embedded engineer should know why they are missing from the
C-library ;-) 

Russell Shaw wrote:

> When doing a newlib build for h8300-hms, it says something like libgloss
> is not supported for h8300-hms, and so does not install any libgloss
> stuff. Being the first micro i've used with gcc, i didn't know what
> should happen. I traced thru all the configure(.in) and makefiles
> to work out how to add libgloss for the h8300-hms, but it was all
> too complicated, even after reading porting.texi which looks like
> a rough first attempt. I looked at other libgloss directories so
> i could put the same thing in a hitachi libgloss directory, but
> all the other micros had different files to each other, and i
> couldn't work out how/if a configure.in should be modified to
> get the new entries. Its also not obvious from looking at the
> other libgloss directories what files are really required and
> what aren't. To compound all that, i tried to work out if the
> existing functions would need to be modified/deleted. I'll
> have another go in a months time.

 The 'libgloss' for the H8/300 is where all the other 'system' targets are,
so it is in the 'newlib/libc/sys/h8300hms' (not in 'h8300' as I remembered
earlier). It is not the only embedded target having its 'libgloss' there,
the 'h8500hms', 'd10v' etc. seem to have their low-level routines there.

 The routines in the 'newlib/libc/sys/h8300hms' will be automatically included
into the resulted 'libc.a'. The 'Makefile.in' there controls the object names,
so splitting the 'syscalls.c' into separate files and replacing the 'syscalls.o'
in the 'Makefile.in' with a list of the splitten routine names, would result
into a more fine-grained library. Keeping them all in the 'syscalls.o' simply
causes the whole 'syscalls.o' always being linked, not only '_write.o' and
'_read.o', if only these are needed. The same has now been done in the 'libgcc.a'
in newer GCC sources, so one can get several kilobytes smaller executables,
when not the whole 'fp-bit.o' will be linked.

 The 'porting.texi' or something should have hinted about the modular structure
in newlib, ie. the lowest-level routines are not splitted everywhere in the sources,
but being in a subdirectory in 'libgloss' or in 'newlib/libc/sys'. So nobody
should need to care (first) about anything else but these directories when
building the self-made glue-library for the self-made target board. Only a small
'module' in the big system must be fixed in order to get the system to work.

 Adding a new target like 'h8300-shaw' with its own glue routines would happen
simply by copying the stuff from 'newlib/libc/sys/h8300hms' into
'newlib/libc/sys/h8300shaw' and adding a new 'system-directory', 'h8300shaw',
into the 'newlib/configure.in' (this may be changed in newlib-1.8.2, but grep'ing
for the 'h8300hms' in the 'newlib' would tell where the definition now is...)
for the new target template 'h8300-shaw'. The 'libc/machine/h8300' etc. should be
selected only via the 'h8300' in the start of the target name...  I have used
this method for adding targets like 'i386-sysv4', using the existing 'sysvi386'
(for SVR3.2) as the basement. This was done in order to get a 'glue library'
for i386-elf, consisting of SVR4-syscalls, so that after linking against 'libc.a' and
'libsvr4.a', the executables would run under Linux with ibcs2 (or under a real
SVR4/i386 like UnixWare). I haven't tried to create a new libgloss target...

 Ok, after making a new target and copied the h8300-hms stuff for it, modifying
the copies wouldn't break anything in the original 'h8300-hms'... Unfortunately
the low-level routines will be included to the 'libc.a' for 'h8300-shaw' in this
scheme, but does it really matter?  If you keep the built objects untouched and
then modify something in the 'newlib/libc/sys/h8300shaw', and write the 'make',
only the modified things will be replaced... When you do 'make install', the libs
will go into '$prefix/h8300-shaw' and you can move them from there or do the
install manually...

 For my 'i386-elf' case, I had first built for the 'i386-elf' and had no low-level
stuff for anything, so I couldn't produce executables for anything. After adding
the 'i386-sysv4', the startup and low-level I/O for a SVR4 system were produced
and I could take the extra stuff from that build into the separate 'libsvr4.a'.

 For the h8300 there doesn't seem to be 'pure' h8300-target, like 'h8300-coff',
for which only the target-independent routines would be built and put into the
'libc.a'. So getting a separate 'libc.a' (without the low-level stuff) and a
'libshaw.a' (with the low-level stuff) for your H8/300 target doesn't seem to
be easy to automatize with this 'system' approach...

Cheers, Kai