This is the mail archive of the newlib@sources.redhat.com 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]

Re: Stdio redirection?


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:

Makefile:

FLAGS = -m68000 -malign-int -Wall -Wa,-alh,-L -DDEBUG2 -fomit-
frame-pointer

CC = m68k-coff-gcc
AR = m68k-coff-ar

testcram.s19 : testcram.o crt0.o
        m68k-coff-ld testcram.o -L/usr/local/m68k-coff/lib/m68000 -
L/usr/local/lib/gcc-lib/m68k-coff/2.95.2/m68000 -M -Tgizmo.ld -
otestcram.s19

Notes:
The compiler flags are just the normal gcc stuff, but I only use
gcc to compile the code and then call the linker directly. gizmo.ld 
is the linker script.  The library paths are for the newlib (libc stuff) 
and gcc's libraries.

Linker script:

STARTUP(crt0.o)
OUTPUT_ARCH(m68k)
OUTPUT_FORMAT(srec)

SEARCH_DIR(.)
GROUP(-lgizmo -lc -lgcc)


/*
 * Setup the memory map of the M68332BCC Business Card 
Computer.
 * stack grows down from high memory.
 *
etc.

I started out with an example from the libgloss directories and 
modified it to suit my needs. gizmo.a contains my support 
functions (hence -lgizmo).

Documentating the embedded gnu environment would make for an 
interesting book.  Unfortunately it doesn't seem to have happened 
yet (something for an Oreilly/Cygnus project?).

Hope that helps.

Noah.

On 6 Oct 2000, at 9:07, Russ.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.
> 
> "Aaron J. Grier" wrote:
> > 
> > On Thu, Oct 05, 2000 at 09:31:10PM +1000, Russ.Shaw wrote:
> > 
> > > Kai Ruottu wrote:
> > > >  Why you should care about this?  Just remove the low-level routines
> > > > from all your libc.a's and provide your own glue libs with them inside.
> > >
> > > If i knew what the right low-level functions were, i would. However,
> > > looking at stdio.h and the newlib sources, there's too many
> > > conditional compilations controlled by variables from unknown places,
> > > compounded by all the extra re-entrant library functions.
> > 
> > all the bare-bones low-level interfacing is done in libgloss.  no need
> > to wade through all of newlib.  I went through this routine when I
> > started with a bare m68k-elf compiler for an in-house embedded system.
> > it took me a while to get oriented, too.
> > 
> > all the details are laid out in libgloss/doc/porting.texi.  stubs can be
> > found in libgloss/libnosys.
> > 
> > > I was going to add to libgloss myself, but there was not sufficient
> > > information in the source docs, on the web, from newsgroups, or
> > > mail-lists.
> > 
> > after reading the "Embed with GNU" document, what's left?
> > 
> > > I had not found anywhere that definitely said that those functions
> > > were at the bottom level with all higher functions using them. A
> > > message by j.johnston referred to a build-time way that suggests these
> > > functions, by modifying configure.in etc (i'm still getting around to
> > > trying it).
> > 
> > I never worried about it at build time -- since it's easy enough to
> > change linker scripts to link in whatever you need, and you can drive
> > yourself crazy dealing with autoconf / automake.  I built an external
> > libgloss and crt0, and linked 'em in by hand/makefile.
> > 
> > > I wire-wrapped my own system and didn't want to add more variables by
> > > using a monitor. I'd be completely happy if there was a
> > > straight-forward obvious method for doing the low-level functions,
> > > knowing that nothing will get broken. And it should be stated
> > > prominantly in docs such as 'using gcc' or similar.
> > 
> > all there in libgloss/doc/porting.texi.  even information on writing a
> > gdb back end.  I'm surprised nobody's mentioned it.  it was one of the
> > first documents I stumbled upon.
> > 
> > here's an online version:
> > http://www.efm.leeds.ac.uk/~as/gnu/info_html/porting_toc.html
> > 
> > of special interest to you will be the section on porting newlib:
> > http://www.efm.leeds.ac.uk/~as/gnu/info_html/porting_3.html#SEC10
> > 
> > happy hacking.
> > 
> 
> -- 
> *******************************************
> *   Russell Shaw, B.Eng, M.Eng(Research)  *
> *      email: russell@webaxs.net          *
> *      Victoria, Australia                *
> *******************************************
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com



------------------------------------------
Noah Aklilu
http://www.ee.ualberta.ca/~aklilu/
naklilu@ualberta.ca

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