Stdio redirection?

Sat Oct 7 06:06:00 GMT 2000

Thanks, that helps a bit.

I just had a look and found the read()/write() stuff in
newlib-src/newlib/libc/sys/h8300hms. For some stupid reason,
i can't remember seeing target systems in there. All along,
i've been looking at the target directories in newlib-src/libgloss.

Why are there two different directories of targets? Its the
unexplained overall structure of the source trees and build
steps that makes working-out problems difficult.

So, if i just modify the read()/write()/sbrk() functions in
newlib-src/newlib/libc/sys/h8300hms, then rebuild, would
that work?

Also, when configuring newlib says libgloss is not supported
for the h8300-hms, what does that mean? The configure stops
at that message too.

Kai Ruottu wrote:
> 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 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 '' there controls the object names,
> so splitting the 'syscalls.c' into separate files and replacing the 'syscalls.o'
> in the '' 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/' (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
> ------
> Want more information?  See the CrossGCC FAQ,
> Want to unsubscribe? Send a note to

*   Russell Shaw, B.Eng, M.Eng(Research)  *
*      email:          *
*      Victoria, Australia                *

More information about the Newlib mailing list