This is the mail archive of the newlib@sourceware.org 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]
Other format: [Raw text]

Re: Add more stubs to RTEMS dummy crt0


On 05/09/2012 04:13 AM, Ralf Corsepius wrote:
On 05/09/2012 11:03 AM, Corinna Vinschen wrote:
On May 7 16:12, Joel Sherrill wrote:
This patch adds more stubs to the RTEMS crt0.c so
autoconf probes for gfortran and Go are happy
with RTEMS. The crt0 stub satisfies symbols which will
really only be available when an actual RTEMS image
is linked against.

OK to apply?

2012-05-07 Joel Sherrill<...>

      * libc/sys/rtems/crt0.c: Add stubs for access(), ftruncate(),
      _getpid_r(), geteuid(), getgid, _getgid_r, getpid(), getppid(),
      and _getpid_r().
Patch applied.
I regret not having vetoed earlier, sorry ;)

It escapes me which issue Joel is trying to address with these stubs,
because these symbols are provided by rtems and are not provided nor
used by newlib.
It is the same issue that crt0.c has solved since before you were
involved with RTEMS. It hasn't changed.
Background: The original rationale for the stubs is to make newlib
selfcontained i.e. to provide sufficient symbols such that all symbols
from newlib can be resolved from inside of newlib. This is sufficient to
compile RTEMS itself.
No. You don't remember why this crt0 is provided or the purpose
of the symbol set. It is true that these are symbols provided by
RTEMS. But the set provided is specifically provided to ensure
that autoconf probes can link and accurately report what is
available in *-rtems when building without having to reference
RTEMS libraries or BSPs.

In particular, some of the first symbols provided in crt0.c were the
malloc family which RTEMS has its own implementation of
and for symbols provided by BSP linker scripts. Autoconf
probes must be able to link and accurately report what functions
are available in the target.

This model is important when building gcc language run-time libraries.
These symbols in particular are from satisfying the autoconf probes
of libgfortran.

All external packages built upon newlib+rtems are supposed to receive all symbols from linking agains "newlib+rtems".

With this patch applied, there is no clear distinction between "pure
newlib" and "newlib + rtems" anymore.
Ralf, there never was a distinction in crt0.c. It is simply the set of
symbols from RTEMS+BSP that are needed to pass autoconf
probes for things built either (1) before RTEMS is built or
(2) in multilib fashion with reference only to newlib. This set has
grown over the years as we have encountered more symbols
in various libraries and added support for more languages
from GCC.

These are needed and these symbols are primarily due to
autoconf probes from libgfortran.

I believe my original comment stated that they were to
satisfy the autoconf probes of gfortran and Go.

Ralf



--
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985



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