[Bug 2111] AVR needs avr-libc to compile RTEMS.
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Tue Apr 9 18:13:00 UTC 2013
Joel Sherrill <joel.sherrill at oarcorp.com> changed:
What |Removed |Added
CC| |joel.sherrill at oarcorp.com
--- Comment #12 from Joel Sherrill <joel.sherrill at oarcorp.com> 2013-04-09 13:13:00 CDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > Found some interesting 'features' of the RTEMS build system.
> > the (unpatched) RTEMS build system only allows *-*-*rtems* targets.
> > (patching away the *-*-*rtems*) targets issue, revealed another issue:
> > cpukit/configure.ac appears to run a POSIX compliance check each time RTEMS is
> > configured, whether posix is enabled (or not).
> > So, for a long-term avr-libc port, we need to pull out the POSIX compliance
> > check into a cpukit/aclocal/enable-posix-compliance-check.m4
> > and add a
> > --enable-posix-compliance-check option to make POSIX compliance checking
> > optional.
> > Apparently cpukit/score requires a struct timeval definition, but I'm not clear
> > as to whether we need score to do the classic rtems library (or not). If we do
> > need score, where should the timeval struct be declared (within rtems, or in
> > avr-libc?) Do we need score to do the ticker demo?
> score contains the scheduling and context switch logic which is needed by
And all RTEMS functionality in the Classic and POSIX API. :)
> However, we replaced struct timeval timestamps with 64-bit integers
> some time ago (although that has been suggested to be reverted), so I think we
> can at the very least conditionalize the code that uses/checks for struct
> timeval, and maybe even eliminate it by moving the timeval dependent code to
> the posix directory. Internally, the score uses Timestamp_Control, which is
> actually either a timespec or a 64-bit integer, so score depends on posix
> timespec when not using 64-bit timestamps.
The implementation of the internal "timestamp" is selected by the architecture.
It is also possible that a new implementation more appropriate for smaller MCUs
could be implemented. That was my thought when providing this as a
Cynthia mentioned that the avr-libc was completely missing sys/time.h so
the port could add an implementation of that file in score/cpu/avr for
now. If avr-libc is willing to add the .h file with this, then it would
be ok long term.
But the posix subdirectory has a few files which are built even when
--disable-posix is specified:
libposix_a_SOURCES += src/nanosleep.c src/clockgettime.c src/clocksettime.c \
These need timespec and clockid_t plus sysconf.c needs the _SC_xxx constants
which are in unistd.h in newlib.
FYI it probably also needs to delete every file under the score/cpu/avr/avr/
directory since those are from an old avr-libc.
> I think this problem you found actually stems from the classic API Clock
> Manager (cpukit/rtems/include/rtems/rtems/clock.h) depends on struct timeval.
struct timespec and timeval are assumed to exist. You could disable
everything that depends on them.
Based on http://en.cppreference.com/w/c, I think these are POSIX and
This goes back to the requirements of what I have called "uRTEMS" for
RTEMS on Microcontrollers. This is almost a throwback to version 1.x of
RTEMS where there was only the Classic API as defined by RTEID/ORKID.
No assumptions on C Library in the score and RTEMS -- not even memcpy.
If building a subset of RTEMS with a C99/C11 compiler and C Library
is the requirement, then you can't use anything with those types
> > I was really amazed that I could compile as much as I did without newlib
> > support!
In twenty years, we haven't broken much since newlib support came in
about 5 years after the project started.
> > So in summary, three issues: target restrictions, posix compliance checking
> > when posix is disabled, and score/timeval.
I think in score/cpu/avr/rtems/score/cpu.h, you should change this to FALSE:
#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
And see how much farther you get. If you don't have timespec though, these
$ ls *spec*
coretodgetuptimetimespec.c timespecfromticks.c timespectoticks.c
timespecaddto.c timespecisvalid.c ts64totimespec.c
And don't worry about anything except C. This is back to answering the
What are the requirements for uRTEMS?
+ C99/C11 Standard Library Dependency only?
+ Classic API only?
+ no BSP TCP/IP stack?
+ stack checker?
I know I am on a requirements kick lately but defining them is important for
this. I believe the Classic API should be OK for uRTEMS minus struct time*
based upon the original design parameters.
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the bugs