diff options
| author | Corinna Vinschen <corinna@vinschen.de> | 2010-09-23 08:07:47 +0000 |
|---|---|---|
| committer | Corinna Vinschen <corinna@vinschen.de> | 2010-09-23 08:07:47 +0000 |
| commit | 49961454868072334f5fc9289820b191260e1dc0 (patch) | |
| tree | 3bc80726db20d6d79ccb09a30c61d9ff35983bac | |
| parent | 631c8d784bccb93a87fb9ef95245548cb81a2fbb (diff) | |
| download | newlib-49961454868072334f5fc9289820b191260e1dc0.zip newlib-49961454868072334f5fc9289820b191260e1dc0.tar.gz newlib-49961454868072334f5fc9289820b191260e1dc0.tar.bz2 | |
* doc/porting.texi: Fix typos.
| -rw-r--r-- | libgloss/ChangeLog | 5 | ||||
| -rw-r--r-- | libgloss/doc/porting.texi | 24 |
2 files changed, 17 insertions, 12 deletions
diff --git a/libgloss/ChangeLog b/libgloss/ChangeLog index 3e14305..23d3dd1 100644 --- a/libgloss/ChangeLog +++ b/libgloss/ChangeLog @@ -1,3 +1,8 @@ +2010-09-23 Mike Frysinger <vapier@gentoo.org> + Corinna Vinschen <vinschen@redhat.com> + + * doc/porting.texi: Fix typos. + 2010-09-22 Mike Frysinger <vapier@gentoo.org> * README: Add bfin to the list. diff --git a/libgloss/doc/porting.texi b/libgloss/doc/porting.texi index eca88ca..9e1d928 100644 --- a/libgloss/doc/porting.texi +++ b/libgloss/doc/porting.texi @@ -104,18 +104,18 @@ the final executable image. Most of the time a tool chain does only have to support one target execution environment. An example of this would be a tool chain for the AMD 29k processor family. All of the execution environments for this -processor are have the same interface, the same memory map, and the same -I/O code. In this case all of the support code is in newlib/sys/FIXME. -Libgloss's creation was forced initially be the @code{cpu32} processor -family. There are many different execution environments for this line, -and they vary wildly. newlib itself has only has a few dependencies that -it needs for each target. These are explained later in this doc. The -hardware dependent part of newlib was reorganized into a separate -directory structure within newlib called the stub dirs. It was initially -called this because most of the routines newlib needs for a target were -simple stubs that do nothing, but return a value to the application. They -only exist so the linker can produce a final executable image. This work -was done during the early part of 1993. +processor have the same interface, the same memory map, and the same +I/O code. In this case all of the support code is under newlib/libc/sys. +Libgloss's creation was forced initially because of the @code{cpu32} +processor family. There are many different execution environments for +this line, and they vary wildly. newlib itself has only a few +dependencies that it needs for each target. These are explained later in +this doc. The hardware dependent part of newlib was reorganized into a +separate directory structure within newlib called the stub dirs. It was +initially called this because most of the routines newlib needs for a +target were simple stubs that do nothing, but return a value to the +application. They only exist so the linker can produce a final +executable image. This work was done during the early part of 1993. After a while it became apparent that this approach of isolating the hardware and systems files together made sense. Around this same time |