The newlib library requires a number of platform dependent stubs to be
implemented by yourself. See the "Systen Calls" documentation for
Newlib. http://sourceware.org/newlib/libc.html#SEC195

If you are using an off-the-shelf board, or a commonly used device,
there is likely to be an existing implementation you can use.

_sbrk_r is required to support dynamic memory allocation. It is platform
dependent in that it needs to know where the heap is to be allocated.

_fstat_r provides status information for an open file, and so is file
system dependent. If you do not have a file system integrated to the
standard library, this is still used by other standard I/O devices such
as serial ports.


The _r suffix indicates that these are the reentrant covers for the
System Calls.

There are other System Calls, but the linker will not complain about
them unless you call a library routine that requires them.

Clifford

Clifford, thank you for your answer.

Just a stupid question for my understanding, please:

Is it a new requirement ? I used several GNUARM versions before
but I have never been requested to use own code for these System
Calls.

Thanks

Robert

Robert Tyrakowski wrote:
> Is it a new requirement ? I used several GNUARM versions before
> but I have never been requested to use own code for these System
> Calls.

It may be that they were already provided for the platform you were
using, or this time you have omitted them from the link, or simply that
previously you did not make any calls that needed them. It is also
possible to build Newlib with syscall stubs built-in, and this is common
for boards with a supported ROM monitor to provide teh necessary
services. If you were using such a build, it would have resolved the
symbols without complaint (although unless you had an appropriate ROM
monitor, it will not have worked correctly).

It is not a new requirement, the library is intended to run on any
platform, with or without an operating system, or ROM monitor. It would
be impossible to make it work without some glue to map it to the OS or
ROM monitor services for memory and device management, or where there is
no OS or ROM monitor, to map it to user provided board support services.
It would be some kind of magic if it were not so.

Clifford

Thank you very much for giving me these background informations.

Nevertheless, I'm still a bit confused, because I do not use an OS or
any kind of
monitor. It's just a piece of SW which runs on an own HW. The same
sources
compiled with a previous GNUARM version works, but with the latest
version it doesn't.

Anyway, I'll try to provide the missing stuff. I still have the option
to go back
to an older version.

Thanks again for your help.

Robert

>
> Anyway, I'll try to provide the missing stuff. I still have the option
> to go back
> to an older version.
>
You may have been relying on someone else's make file linking stuff you
just took for granted perhaps. Anyway since there is no substiture for
really knowing what is going on and how to put it all together yourself,
I recommend that you take a look at
http://www.state-machine.com/resources/papers.htm ( or in PDF
http://www.state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf ).


Clifford

Robert Tyrakowski wrote:
> Hello,
>
> After I changed to bu-2.19_gcc-4.3.2-c-c++_nl-1.16.0_gi-6.8.exe,  I'm
> getting linker errors for a certain project. Other projects work without
> problems.
>
> Using version bu-2.17_gcc-4.1.1-c-c++_nl-1.14.0_gi-6.5.exe , everything
> is also ok with all projects.
>
> Could anybody advice please ?

This looks like a package-name from gnuarm.org? Did you try to ask in
the gnuarm yahoo-group?

Did you try to build with the Codesourcery package arm-none-eabi-* (the
lite version is free but does not include Insight GDB).

> Examples for the error messages:
>
> Description  Resource  Path  Location  Type
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdio/../../../../../newlib-1.16 
.0/newlib/libc/stdio/makebuf.c
> undefined reference to `_fstat_r'  gps-landing    59  C/C++ Problem
> Description  Resource  Path  Location  Type
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdio/../../../../../newlib-1.16 
.0/newlib/libc/stdio/stdio.c
> undefined reference to `_close_r'  gps-landing    124  C/C++ Problem
>
> ....
>
> and more
>
> C:/Programme/GNUARM/arm-elf/lib/libc.a(lib_a-freer.o): In function
> `_malloc_trim_r':
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.1 
6.0/newlib/libc/stdlib/mallocr.c:3326:
> undefined reference to `_sbrk_r'
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.1 
6.0/newlib/libc/stdlib/mallocr.c:3335:
> undefined reference to `_sbrk_r'
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.1 
6.0/newlib/libc/stdlib/mallocr.c:3340:
> undefined reference to `_sbrk_r'
> C:/Programme/GNUARM/arm-elf/lib/libc.a(lib_a-makebuf.o): In function
> `__smakebuf_r':
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdio/../../../../../newlib-1.16 
.0/newlib/libc/stdio/makebuf.c:59:
> undefined reference to `_fstat_r'
> C:/Programme/GNUARM/arm-elf/lib/libc.a(lib_a-mallocr.o): In function
> `malloc_extend_top':
> /c/gnu/newlib-build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.1 
6.0/newlib/libc/stdlib/mallocr.c:2160:
> undefined reference to `_sbrk_r'
>
> .....
>
> make: *** [gpsrcl.elf] Error 1

Beside of what Clifford already mentioned: There might be some kind of
side-effect from the library, an embedded function that pulls in
dependencies to the syscalls (maybe "exit", "assert" or something like
this). It depends a little bit on how the newlib got configured. Can you
create a minimal example to reproduce the issue (assembler-startup,
source-codes, linker-script, makefile) and attach it to a message to
this forum or send it to the known e-mail address.

Clifford and Martin, thanks a lot for your help.

Find some further comments below.

> This looks like a package-name from gnuarm.org? Did you try to ask in
> the gnuarm yahoo-group?
>
No, not yet. I was not aware to ask at Yahoo. But now I found there ,
that
I'm possible  one of the million user who asked for a similar issue.
A first quick few points to something like
--disable-supplied-newlib-syscalls
during newlib build process. But I didn't build it.

> Did you try to build with the Codesourcery package arm-none-eabi-* (the
> lite version is free but does not include Insight GDB).
>
No, I didn't . I always use the same source for the compiler. You know,
I'm
not a GNU expert. I always hope I must not touch anything ! I'm still
using the
same environment (makefile and the other stuff) you helped me to set up
almost
two years ago.

>
> Beside of what Clifford already mentioned: There might be some kind of
> side-effect from the library, an embedded function that pulls in
> dependencies to the syscalls (maybe "exit", "assert" or something like
> this). It depends a little bit on how the newlib got configured. Can you
> create a minimal example to reproduce the issue (assembler-startup,
> source-codes, linker-script, makefile) and attach it to a message to
> this forum or send it to the known e-mail address.

Thanks for the offer. First I'll try to find a solution by myself. If
I'm not successful, I'll come back to your offer. The mail address is
known.

Thank you again.

Regards

Robert

Robert Tyrakowski wrote:

> A first quick few points to something like
> --disable-supplied-newlib-syscalls
> during newlib build process. But I didn't build it.
>
Newlib builds intended for arbitrary targets may have been built like
that. As far as I recall, the supplied syscalls assume the Angel ROM
Monitor supplied with a number of commercial ARM boards.

Even if they were built-in, they can be overridden by linking object
files that define them, or by linking a library that defines them ahead
of the Newlib library (libc.a).

Is it possible perhaps that you have changed the link order between libc
and the support library providing these calls? Time to post your
complete build log perhaps?

Clifford