Hi,
thank you very much for your explanation and the provided source code,
but I think you misunderstood me. I have written the routines _write_r
and _read_r and so on. I compiled these new written functions and
build my own small library called libosarm.a . If I disassemble this
library there is the correct assembler code inside. But if I link my
project with arm-elf-gcc $FLAGS -o tst *.o -Wl,-verbose -losarm I can
see that the linker opens my library, but after that he opens libc.a
and shows the errors.
regards, miru
--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> miruffer wrote:
>
> >Hi,
> >
> >thank you for your answer. I look at your scripts and have seen that
> >you use the flag --disable-newlib-supplied-syscalls. I have rebuilt my
> >GNU Toolchain.
> >When the linker links my project, there are the errors shown below.
> >
> >
> >
>
> Absolutely correct. You've done it the right way. Now, if you want to
> know what can be done with those missing routines, also get a copy of
> the RDCF2 filesystem source (also from my site). *You* provide those
> functions: write_r, open_r, etc..
>
>
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(writer.o):
> >In function `_write_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/writer.c:58: undefined
> >reference to `_write'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(closer.o):
> >In function `_close_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/closer.c:53: undefined
> >reference to `_close'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(fstatr.o):
> >In function `_fstat_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/fstatr.c:62: undefined
> >reference to `_fstat'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(lseekr.o):
> >In function `_lseek_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/lseekr.c:58: undefined
> >reference to `_lseek'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libc.a(readr.o):
> >In function `_read_r':
> >../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined
> >reference to `_read'
>
>/opt/arm-tools/lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib/libstdc++.a(eh_personality.o):
> >
> >
> >
> >All the functions he can't find, are exsisting in my own libary the
> >linker had opend before. I can't understand that.
> >
> >
> >
> >
> When you compile newlib, without the stubs, it assumes that it will be
> dealing with an operating system which would provide a call entry
> structure to perform device I/O. Since you are not using an operating
> system, such as Linux, you have to provide that last bit of code to
> bridge between the library (abstraction) and your hardware (reality).
>
> The newlib, nor any library, is intended to provide a "final
solution".
> They cannot, hardware varies from environ to environ. It is up to you,
> ultimately, to see that the "operating system" provide a means to move
> the data stream coming out of the library over to the hardware. With
> something like Linux, we do this be means of the various hardware
driver
> code and the SysCalls. When you don't have an operating system, the
> same requirement still exists to physically connect the data stream
from
> the library to the hardware.
>
> This is what the RDCF2 code is about. It illustrates how to do device
> (hardware) interfacing to newlib, so that you can use filestreams such
> as: fopen(), fread(), fwrite(), fgetc(), etc.. I only provided code to
> interface to an SD drive. The application that I'm building does not
> require, nor tolerate, file streams to the serial port(s). Having said
> that, you can add a device "UARTx" to the device table, then add
another
> file identical in structure to that of 'mmc_module.c'. Take a look at
> that file, at the bottom is the DEVICE_TABLE_ENTRY struct which
provides
> the entry points to get work done. This is the "final link" between
> newlib and the hardware. The write_r, read_r, open_r code I provide is
> the mechanism to handle multiple data streams and to direct those
> streams to the various hardware.
>
> I had taken a general purpose approach to implementing the stub code.
> There are two key elements of the interfacing process: adding a new
> device to the DeviceTable array, adding a new module which contains the
> implementation of the device entry. The code in between, all those
> ending in "*_r.c" do not need to be altered.
>
> 1. devices.c contains the device table.
> 2. sysdefs.h contains the device IDs.
> 3. mmc_module.c illustrates the implementation of the device.
>
> You simply add your new module code and make an entry into the
device table.
>
> I see that this may be confusing to a first time user of libraries on
> embedded systems. All embedded system libraries function in
essentially
> the same manner. Ultimately, there has to be "bridging code"
written by
Show quoted textHide quoted text
> the end-user to provide a link between the hardware and the library.
>
> While you could get deep inside the guts of newlib and hack your way
> into getting the write() function to give you an output you desire, I
> would advise against it.
>
>
> TomW
>
>
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>