Custom Query (59 matches)

if pax is not found by configure, the tests fail to build un-gracefully.

If pax is not found by configure, the empty PAX variable is used in e.g. this line:

$(PAX) -w -f $@ $<

Causing the 'w' command to be invoked:

21:37:25 up 6 min, 3 users, load average: 1,90, 1,14, 0,49

USER TTY LOGIN@ IDLE JCPU PCPU WHAT ../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c ../../../../../../tools/build/rtems-bin2c -H dl.tar dl-tar.h cannot open dl.tar for reading cannot open dl.tar for reading make[6]: * [dl-tar.c] Error 1 make[6]: * Waiting for unfinished jobs.... make[6]: * [dl-tar.h] Error 1 make[6]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests/dl01' make[5]: * [all-local] Error 1 make[5]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests' make[4]: * [all] Error 2 make[4]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests' make[3]: * [all-recursive] Error 1 make[3]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites' make[2]: * [all-recursive] Error 1 make[2]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack' make[1]: * [all-recursive] Error 1 make[1]: Leaving directory `/home/beng/development/rtems/b-beagle/arm-rtems4.11/c' make: * [all-recursive] Error 1

I am preparing a proposed fix that fails more gracefully in the configure phase.

Thanks to several reporters of this problem, most recently Debajyoti Majumdar and Claudio Scordino, while trying to build the tests with the Beagle BSP.

rtems/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c:98]: (warning) Found calculation inside sizeof().

Source code is

if ( strncmp( opt, "fbcons", sizeof( "fbcons" - 1 ) ) == 0 ) {

Maybe better code

if ( strncmp( opt, "fbcons", sizeof( "fbcons") - 1 ) == 0 ) {

or1k Linking error on C++ tests

I fixed the header file issue in 2326. This is a new issue which is either a linker script or tools issue not having everything right for C++.

gmake[6]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/testsuites/samples/iostream' or1k-rtems4.11-g++ -B../../../../../or1ksim/lib/ -specs bsp_specs -qrtems -O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -O2 -o cxx_iostream.exe init.o init.o: In function `static_initialization_and_destruction_0': /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/iostream:74: undefined reference to `dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/include/c++/iostream:74: undefined reference to `dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/libstdc++.a(atomicity.o): In function `get_atomic_mutex': /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1/build/or1k-rtems4.11/libstdc++-v3/src/c++98/atomicity.cc:33: undefined reference to `dso_handle' /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1/build/or1k-rtems4.11/libstdc++-v3/src/c++98/atomicity.cc:33: undefined reference to `dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/libstdc++.a(eh_alloc.o): In function `static_initialization_and_destruction_0': /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1/build/or1k-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.8.3/libstdc++-v3/libsupc++/eh_alloc.cc:96: undefined reference to `dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/libstdc++.a(eh_alloc.o):/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/or1k-rtems4.11-gcc-4.8.3-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1/build/or1k-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.8.3/libstdc++-v3/libsupc++/eh_alloc.cc:96: more undefined references to `dso_handle' follow /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/../../../../or1k-rtems4.11/bin/ld: cxx_iostream.exe: hidden symbol `dso_handle' isn't defined /users/joel/rtems-4.11-work/tools/lib/gcc/or1k-rtems4.11/4.8.3/../../../../or1k-rtems4.11/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status gmake[6]: * [cxx_iostream.exe] Error 1

pc386 build fails

When building RTEMS for pc386 make all fails after executing bootstrap and configure by

../rtems/configure --target=i386-rtems4.11 --enable-rtemsbsp=pc386 --enable-tests=samples --disable-posix

at entering .../samples/hello with undefined reference to pthread_mutex_trylock and undefined reference to pthread_mutex_unlock

When commenting lines 869-874, 891-892, 899-901 in development/rtems/src/rtems/c/src/lib/libbsp/i386/pc386/console/fb_vesa_rm.c the build succeeds.

 860 rtems_device_driver
 861 frame_buffer_open(
 862     rtems_device_major_number  major,
 863     rtems_device_minor_number  minor,
 864     void                      *arg
 865 )
 866 {
 867     printk( FB_VESA_NAME " open device\n" );
 868 
 869     //if (pthread_mutex_trylock(&vesa_mutex) != 0)
 870     //{
 871     //    printk( FB_VESA_NAME " could not lock vesa_mutex\n" );
 872 
 873     //    return RTEMS_UNSATISFIED;
 874     //}
 875 
 876     return RTEMS_SUCCESSFUL;
 877 
 878 }
 879 
 880 /*
 881  * fb_vesa device driver CLOSE entry point
 882  */
 883 rtems_device_driver
 884 frame_buffer_close(
 885     rtems_device_major_number  major,
 886     rtems_device_minor_number  minor,
 887     void                      *arg
 888 )
 889 {
 890   printk( FB_VESA_NAME " close device\n" );
 891   //if (pthread_mutex_unlock(&vesa_mutex) == 0)
 892   //{
 893       /* restore previous state.  for VGA this means return to text mode.
 894        * leave out if graphics hardware has been initialized in
 895        * frame_buffer_initialize() */
 896 
 897       printk(FB_VESA_NAME ": close called.\n" );
 898       return RTEMS_SUCCESSFUL;
 899   //}
 900 
 901   //return RTEMS_UNSATISFIED;
 902 }

Remove LICENSE.WEBSERVER

This file is for the GoAhead? webserver and no longer should be in the tree. Filing a ticket because I think this file is also on branches where the GoAhead? webserver is no longer present.

We also may want to add a note to the file on the rtems.org website to indicate that this webserver was removed as of 4.11? release series.

This just needs some homework and a doublecheck.

Beaglebone: bsp.h missing clobber in inline assembly.

flush_data_cache uses R0 directly but doesn't list it as a clobbered register. Compiling with -O3 made this code break, since the function that calls flush_data_cache already uses r0.

CppCheck? errors being reported throughout the code

I performed a run of cppcheck --enable-all on the git master and the following items were reported as 'error':

[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of character ({) when these macros are defined: '__cplusplus'.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior: Variable 'line_buffer' is used as parameter and destination in s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior: Variable 'line_buffer' is used as parameter and destination in s[n]printf().
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc mistake: 'dhcp_hostname' nulled but not freed upon failure
[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:104]: (error) Invalid number of character ({) when these macros are defined: '__cplusplus'.
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:582]: (error) Memory leak: new_prefix

Notice I ran cppcheck mostly on the modules I'm currently using (that means most BSPs weren't checked). Some other errors may show up when running it on the entire source.

rtems_dhcp.c fails to compile ("free" requires an extra argument)

When trying to compile rtems_dhcp.c, compilation will fail with the following error:

../../../../../../trunk/c/src/../../cpukit/libnetworking/rtems/rtems_dhcp.c:408:32: error: macro "free" requires 2 arguments, but only 1 given

free (dhcp_hostname);

dumpbuf.c compiles with warnings

Compiling dumpbuf.c causes the following warning to be issued multiple times:

warning: pointer targets in passing argument 1 of 'snprintf' differ in signedness [-Wpointer-sign]

This seems to happen because line_buffer is declared as unsigned.

[PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()

_CPU_Counter_read(), called e.g., when RTEMS profiling is enabled, attempts to use the mftb instruction to access the time base. This instruction does not exist on Book E processors (such as the e500 used in the MVME3100) and causes an exception on those architectures.

At least RTEMS profiling therefore does not work at least with the mvme3100 BSP.

This...:

diff --git a/cpukit/score/cpu/powerpc/rtems/score/cpu.h b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
index 06cab2c..45298a4 100644
--- a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
@@ -842,7 +842,7 @@ static inline CPU_Counter_ticks _CPU_Counter_read( void )
   /* Use Alternate Time Base */
   __asm__ volatile( "mfspr %0, 526" : "=r" (value) );
 #else
-  __asm__ volatile( "mftb %0" : "=r" (value) );
+  __asm__ volatile( "mfspr %0, 268" : "=r" (value) );
 #endif
 
   return value;

...sorts it out on the mvme3100 and I don't *think* will break anything for other BSPs (I believe SPR 268 is always valid).

I wonder if we wouldn't be better off using PPC_Get_timebase_register(), though, which also checks the upper 32-bits of the timebase? Maybe that doesn't matter for the cases where _CPU_Counter_read() 's called?

[PATCH] [NFS client] Respect 2^{32 - 1 B NFSv2 maximum file size}

The RTEMS NFS(v2) client in at least 4.11 and master does not range check off_t values before assigning them into NFSv2's on-the-wire 32-bit unsigned file offset field.

Reads from and writes to an offset at or above 4 GiB will currently silently be remapped to the mod 2^{32 location (on two's complement machines at least).}

The attached patch checks for negative offsets [1] and out of [0 - UINT32_MAX)-range access in nfs_file_read(), nfs_file_write() and nfs_file_ftruncate(). It doesn't touch the lseek() implementation, so an lseek() past NFSv2 range will still "succeed" - a subsequent read or write there won't. I think this is POSIX-compliant [2], however.

[1] Perhaps unnecessary if it's impossible for a negative offset to be obtained without e.g., an application user twiddling things they shouldn't? lseek() at least does correctly error on obtaining negative offsets

[2] e.g., ​http://pubs.opengroup.org/onlinepubs/009695399/functions/lseek.html doesn't explicitly seem to require lseek() to fail for out-of range offsets that aren't negative, and it mustn't do a resize itself

pthread_cancel() invalidates the thread identifier

A thread that calls pthread_cancel() is no longer able to do a pthread_join() afterwards. This problem appears in a least one GCC test case (libstdc++-v3/testsuite/30_threads/thread/native_handle/cancel.cc).

sem_init() does not honour SEM_VALUE_MAX

sem_init() succeeds even if the initial value exceeds SEM_VALUE_MAX.

gpio functions in bsp name improvement

Fixes GPIO APIs Naming Convention and Comments.

Thanks to Sudarshan Rajagopalan <sudarshan.rajagopalan@…> for reporting this and the patch. Slightly revised patch will follow that auto-closes this bug.

This change renames these gpio-specific functions:

rtems_bsp_enable_interrupt rtems_bsp_disable_interrupt rtems_bsp_select_specific_io

to

rtems_gpio_bsp_enable_interrupt rtems_gpio_bsp_disable_interrupt rtems_gpio_bsp_select_specific_io

Invalid configuration option used in virtex bsp headers

virtex4 and virtex5 bsp headers (bsp.h) define CONFIGURE_INTERRUPT_STACK_MEMORY, which causes confdefs.h to choke.

As discussed on mailing list, they should instead set BSP_INTERRUPT_STACK_SIZE.

Beaglebone Black: rtems_gpio_bsp_disable_interrupt disables all the GPIO interrupts

While testing the BBB GPIO code we noticed rtems_gpio_bsp_disable_interrupt seems to disable the interrupts for all the pins, not just the one that actually caused the interrupt.

beagle sdcard.sh has hard-coded rtems arm-rtems4.11-objcopy

(This is the script that generates an SD card image ready to boot RTEMS.)

switching to the rtems 4.12 toolchain requires this:

+++ b/c/src/lib/libbsp/arm/beagle/simscripts/sdcard.sh
@@ -59,7 +59,7 @@ $PREFIX/bin/newfs_msdos -r 1 -m 0xf8 -c 4 -F16  -h 64 -u 32 -S 512 -s $FATSIZE -
 
 # Prepare the executable.
 base=`basename $executable`
-$PREFIX/bin/arm-rtems4.11-objcopy $executable -O binary $TMPDIR/$base.bin
+$PREFIX/bin/arm-rtems4.12-objcopy $executable -O binary $TMPDIR/$base.bin
 gzip -9 $TMPDIR/$base.bin
 $PREFIX/bin/mkimage -A arm -O rtems -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS -d $TMPDIR/$base.bin.gz $TMPDIR/$ap
 echo "setenv bootdelay 5

Of course I'm open to a cleaner fix.

Could the software be downloaded at the beginning?

I really appreciate having the RTEMS Source Builder!

Could we change the software to download first, then build? If we did that, then we would not be tied to the internet for the rest of the build...

Thanks!

CVS command failure clean up.

If a CVS checkout command fails it is best to clean up the directory or at least determine the state of the directory before a checkout.

Better error report to the user could also help.

rtems-tools built in RSB on Linux fails to install

Recently I have received reports of RTEMS Tools not installing when built inside the RSB. SO far I have only received these reports on Linux. The logs show waf fails to install with an error message similar to:

+ install /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-joel/users/joel/rtems-4.11-work/tools/bin/rtems-test (from tester/rtems-test)
+ install /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-joel/users/joel/rtems-4.11-work/tools/share/rtems/tester/config/base.cfg (from tester/config/base.cfg)
+ install /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-joel/users/joel/rtems-4.11-work/tools/share/rtems/tester/config/checks.cfg (from tester/config/checks.cfg)
Waf: Leaving directory `/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/build'
Build failed
Traceback (most recent call last):
  File "/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/.waf-1.7.16-9ca17eb492c97b689870b4ff9db75880/waflib/Task.py", line 123, in process
    ret=self.run()
  File "/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/.waf-1.7.16-9ca17eb492c97b689870b4ff9db75880/waflib/Task.py", line 47, in run
    return m1(self)
  File "/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/.waf-1.7.16-9ca17eb492c97b689870b4ff9db75880/waflib/Build.py", line 460, in run
    return self.generator.exec_task()
  File "/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/.waf-1.7.16-9ca17eb492c97b689870b4ff9db75880/waflib/Build.py", line 476, in exec_install_files
    self.generator.bld.do_install(y.abspath(),destfile,self.chmod)
  File "/users/joel/rtems-4.11-work/rtems-source-builder/rtems/sources/git/rtems-tools.git/.waf-1.7.16-9ca17eb492c97b689870b4ff9db75880/waflib/Build.py", line 517, in do_install
    shutil.copy2(src,tgt)
  File "/usr/lib64/python2.7/shutil.py", line 131, in copy2
    copystat(src, dst)
  File "/usr/lib64/python2.7/shutil.py", line 98, in copystat
    os.utime(dst, (st.st_atime, st.st_mtime))
OSError: [Errno 2] No such file or directory: '/users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-joel/users/joel/rtems-4.11-work/tools/bin/rtems-test'

shell cmd failed: /bin/sh -ex  /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/rtems-tools-HEAD-1/doit
error: building rtems-tools-HEAD-1
  See error report: rsb-report-rtems-tools-HEAD-1.txt
Build Set: Time 0:17:12.968852

RSB builds 3rd party packages as Canadian Cross (Cxc) packages

The RSB builds the NetSMP package as Canadian Cross (Cxc) so does not install the built package. Cxc packages are not installed because they have prefix paths that may not exist on a build machine plus what is built is not for the build machine so installing is disabled.

Fixing the Cxc logic in the RSB results in the Cxc of ming32 built on FreeBSD to fail.

rtems_waf: SMP support is broken

waf configure --prefix=/opt/rtems-4.12 --rtems=/opt/rtems-4.12 --rtems-tools=/opt/rtems-4.12 --rtems-bsps=arm/altcycv_devkit_smp --rtems-version=4.12

leads to

Checking for RTEMS headers : no One of the tests has failed, see the config.log for more information (complete log in /scratch/git-rtems-libbsd/build/config.log)

due to Checking for RTEMS headers ==> #include <rtems.h>

int main() {

return 0;

}

<== [1/2] [32mcxx: build/.conf_check_43c32d88444a1ba1e9b68cfe1006373a/test.cpp -> build/.conf_check_43c32d88444a1ba1e9b68cfe1006373a/testbuild/test.cpp.1.o [0m ['/opt/rtems-4.12/bin/arm-rtems4.12-g++', '-qrtems', '-B/opt/rtems-4.12/arm-rtems4.12/lib/', '-B/opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/', '--specs', 'bsp_specs', '-march=armv7-a', '-march=armv7-a', '-mthumb', '-mthumb', '-mfpu=neon', '-mfpu=neon', '-mfloat-abi=hard', '-mfloat-abi=hard', '-mtune=cortex-a9', '-mtune=cortex-a9', '../test.cpp', '-c', '-o', 'test.cpp.1.o'] err: In file included from /opt/rtems-4.12/lib64/gcc/arm-rtems4.12/5.2.1/include/c++/atomic:38:0,

from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/score/cpustdatomic.h:32, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/score/cpuatomic.h:12, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/score/atomic.h:20, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/score/thread.h:24, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/score/heap.h:22, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems/rtems/types.h:26, from /opt/rtems-4.12/arm-rtems4.12/altcycv_devkit_smp/lib/include/rtems.h:31, from ../test.cpp:1:

/opt/rtems-4.12/lib64/gcc/arm-rtems4.12/5.2.1/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

#error This file requires compiler and library support for the \

ARM cache problem after libdl load

• RTEMS Version: Branch "4.11", commit edf77328c1813e15a293841dd33995fb11bd4bec
• System type: ARM Cortex-A9, Xilinx Zynq 7020, xilinx_zynq_zedboard BSP
• Compiler toolchain version: GCC 4.9.3, Newlib 2.2.0.20150423, Binutils 2.24
• RTEMS configure options: --target=arm-rtems4.11 --enable-rtemsbsp="xilinx_zynq_a9_qemu xilinx_zynq_zedboard" --enable-posix --prefix=$HOME/development/rtems/4.11 --enable-tests
• Code used to reproduce: ​testsuites/libtests/dl01

Expected Behavior

Successful execution of the loaded function from dl-o1.o. Note that the dl01 example runs successfully in QEMU with the xilinx_zynq_a9_qemu BSP.

Actual Behavior

System crash on execution of loaded code. After the first branch is taken to loaded code (dl-load.c:54), GDB indicates that the processor is executing instructions at the correct address, but they do not behave as expected, eventually leading to the system rebooting.

After discussion on the users mailing list, it was found that flushing the data cache and invalidating the instruction cache before calling the loaded function resulted in its successful execution. This was tested by adding the following at dl-load.c:54:

rtems_cache_flush_entire_data();
rtems_cache_invalidate_entire_instruction();

Update Hello World Instructions to include MSYS2

A ticket to prod Chris into adding to the (GSOC Getting Started) MSYS2 instructions.

This needs to be done in time for Google Code-In.

RSB 4.11 tool build broken

Multiple targets: powerpc and i386 Multiple hosts: Ubuntu Wheezy, Debian Jessie, Fedora recent, and CentOS 6

+ cd /home/joel/rtems-hilo-work/rtems-source-builder/rtems/build/rtems-tools-4.11-1 + echo '=> rtems-tools-4.11-1:' + echo '==> %prep:' ++ pwd + build_top=/home/joel/rtems-hilo-work/rtems-source-builder/rtems/build/rtems-tools-4.11-1 + rtems_tools_source=rtems-tools-4.11 + cd /home/joel/rtems-hilo-work/rtems-source-builder/rtems/build/rtems-tools-4.11-1 + /bin/rm -rf rtems-tools-4.11 + ln -s /home/joel/rtems-hilo-work/rtems-source-builder/rtems/sources/git/rtems-tools.git + cd rtems-tools-4.11 /home/joel/rtems-hilo-work/rtems-source-builder/rtems/build/rtems-tools-4.11-1/doit: line 85: cd: rtems-tools-4.11: No such file or directory shell cmd failed: /bin/sh -ex /home/joel/rtems-hilo-work/rtems-source-builder/rtems/build/rtems-tools-4.11-1/doit error: building rtems-tools-4.11-1

RSB qemu bset issues and failure

Trying to build qemu on RSB master, I got errors for qemu_version and rtems_version not being defined. I added the following lines to bare/config/devel/qemu.bset which may or may not be correct but seemed to work.

%define qemu_version 42d58e7c6760cb9c55627c28ae538e27dcf2f144 %define rtems_version 4.12

May also be broken on 4.11 branch. Did not check.

../source-builder/sb-set-builder --log=l-qemu.txt --prefix=/home/joel/rtems-class-201604/tools/4.12 devel/qemu

glib cfg file is missing hash. Fails in release mode

glib is missing the hash. Following patch should fix it. Found on master, likely impacts all branches.

diff --git a/bare/config/devel/glib-2.39.3-1.cfg b/bare/config/devel/glib-2.39.3-1.cfg index 405e511..ab289db 100644 --- a/bare/config/devel/glib-2.39.3-1.cfg +++ b/bare/config/devel/glib-2.39.3-1.cfg @@ -11,6 +11,7 @@

%define glib_version_major 2.39 %define glib_version_minor 3 %define glib_version %{glib_version_major}.%{glib_version_minor}

+%hash md5 glib-%{glib_version}.tar.xz c8ddc045e12cfafdea607c138f3f8429

# # The GLib build instructions. We use 2.x.x Release 1.

Remove Texinfo Documentation

With the converted documentation now suitable for public distribution and the new Sphinx documentation being the official documentation source, the Texinfo documentation source in the development tree needs to be removed.

The patch is against the master but should apply easily to 4.11. Patch is too large to attach. Placed it at:

​ftp://ftp.rtems.org/pub/rtems/people/joel/patches/0001-Remove-texinfo-format-documentation.-Replaced-by-Sph.patch.xz

Chris, please apply and commit to 4.11 and master when it makes sense in the 4.11 release sequence. Then close this ticket.

Thanks.

4.11.0 has incorrect version information

The version info in the tarball is wrong. We need to review Makefile.maint and make sure we are doing similar actions. The version.m4 files definitely need to be updated.

Strict order mutex introduces unbounded priority inversion

The option to ENABLE_STRICT_ORDER_MUTEX is not implemented correctly. It can introduce an unbounded priority inversion in certain circumstances. See ​http://www.rtems.com/ml/rtems-users/2009/may/msg00093.html and the spsem02 test case http://www.rtems.org/pipermail/rtems-devel/2013-May/003154.html

cpustdatomic.h on 16 and 64 bit architectures

Gedare.. sending this one to you since I think you will have a quick solution to this based on your sparc64 porting experience.

This warning occurs 1908 times in the build of the two sparc64 BSPs:

../../cpukit/../../../usiii/lib/include/rtems/score/cpustdatomic.h: In function '_CPU_atomic_Fetch_sub_ptr': ../../cpukit/../../../usiii/lib/include/rtems/score/cpustdatomic.h:374:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

return (void *) val;

It also occurs on the m32c/m32csim and h8300/h8sxsim but not h8300/h8sim.

It would clean up the build logs a lot to get rid of it.

RTEMS printf warnings - newlib's inttypes.h and gcc's newlib-stdint.h

This is a ticket to track the thread and proposed patch here:

​https://sourceware.org/ml/newlib/2014/msg00804.html

There is an inconsistency between newlib's inttypes.h and gcc's newlib-stdint.h which makes it impossible to resolve some printf() warnings across all targets.

The solution is to make newlib-stdint.h use the same logic as glibc-stdint.h (which the patch does) or use per-architecture conditionals in newlib's inttypes.h to detect the inconsistencies and define the correct PRIxxx types.

I would like to see this resolved before 4.11 but will let it slide until 4.11.1.

ampolish3 script can't always find perl

Posted to devel@ ​https://lists.rtems.org/pipermail/devel/2015-July/011984.html

diff --git a/ampolish3 b/ampolish3 index aaa9757..23c2855 100755 --- a/ampolish3 +++ b/ampolish3 @@ -1,4 +1,4 @@ -#! /usr/bin/perl -w +#! /usr/bin/env perl

# # Copyright (C) 2005, 2006 Ralf Cors<C3><A9>pius, Ulm, Germany #

Ensure ada-tests build

There is a compile error in ada-tests/support/init.c.

Incorrect title for C User's Guide in info output

I usually read RTEMS document in Info file format, and I found that C Users' Guide is not correctly set for its dir entry, and hence couldn't be found after 'make install'. This is just a one line fix as follows:

In doc/user/c_user.texi:

-* RTEMS C User: (C Users Guide). The C User's Guide. +* RTEMS C User: (c_user). The C User's Guide.

After this fix, configure with --enable-docs and make install, C Users' Guide can be found by Emacs Info reader without modifying dir entry. Thanks.

Update Applications Ada User's Guide

Update the Applications Ada User's Guide to REST format.

Enable libgomp build in GCC

libgomp is the support library for OpenMP code emitted by GCC. Adding support for RTEMS needs roughly the following steps:

• Move <semaphore.h> header file from RTEMS to Newlib. Due to license issue use the one provided by FreeBSD and modify it accordingly.
• Add Autoconf code to detect presence of Newlib <semaphore.h>.
• Add RTEMS tweaks to libgomp configure script.
• Add RTEMS specific link-time configuration to select a special memory allocator for libgomp.
• Add ability to control thread scheduler, priority, stack size, etc. via application configuration options/handler.
• Add standard OpenMP tests to RTEMS testsuite.
• Add documentation to user manual.
• Do performance tests.
• Add dedicated low-overhead barriers.

sptls01 fails on sis

This fails on sis. Marking for milestone 4.11 until Sebastian gets a chance to look at it and decide if this should work.

Starting program: /users/joel/rtems-4.11-work/b-sis/sparc-rtems4.11/c/sis/testsuites/sptests/sptls01/sptls01.exe

* BEGIN OF TEST SPTLS 1 * TLS item = 0 ../../../../../../../rtems/c/src/../../testsuites/sptests/sptls01/init.c: 36 tls_item == expected [Inferior 1 (process 42000) exited normally]

fsfseeko01 invalid on some architectures

There is a target dependent issue with fsfseeko01. The value it seeks to does not necessarily overflow. On some targets, it remains a valid value. I haven't checked every target but I recall seeing this test fail during my earlier test runs. So far I can confirm this test is not valid on the lm32 and or1k.

Works: sparc, psim, jmr3904 Fails: lm32, or1k, simsh

I am not sure how the logic fails but give instructions, we can probe the gcc's and see what is reported and slipping through. The test attempts to pass in an invalid seek value based on the size of some types and this logic must not be right on all targets.

* BEGIN OF TEST FSFSEEKO 1 *

Breakpoint 3, test ()

at ../../../../../../../rtems/c/src/../../testsuites/fstests/fsfseeko01/init.c:61

61 rv = fseeko(file, off, SEEK_SET); (gdb) n 62 rtems_test_assert(rv == 0); (gdb) 63 rtems_test_assert(errno == 0); (gdb) 65 errno = 0; (gdb) 66 actual_long_off = ftell(file); (gdb) p off $1 = 2147483647 (gdb) n 67 rtems_test_assert(actual_long_off == -1L); (gdb) p actual_long_off $2 = 2147483647 (gdb)

Wrong alignment of ARM exception frame

The stack pointer must be aligned on 8 byte boundary on ARM, so the size of the exception frame must be a multiple of 8 bytes. Otherwise we might/will get an alignment fault, when executing code in the data abort handler for example.

See the attached patch.

PowerPC BSPs that do not build

This is a 4.11 branching blocker!!

powerpc-br_uid powerpc-hsc_cm01 powerpc-mpc8309som powerpc-mpc8313erdb powerpc-mpc8349eamds

See ​https://lists.rtems.org/pipermail/users/2015-July/029230.html

Ioctl extension for termios

The termios driver shall be extended that I/O control commands can be handled.

c/src/lib/libbsp/arm/nds/libfat/source/directory.c:768: possible bad compare ?

[rtems/c/src/lib/libbsp/arm/nds/libfat/source/directory.c:768]: (warning) Char literal compared with pointer 'tmpCharPtr'. Did you intend to dereference it?

while ((tmpCharPtr != '\0') && (j < 12)) {

RSB get stuck building: expat-2.1.0-x86_64-w64-mingw32-1

When running: "$ ../source-builder/sb-set-builder --log=1-sparc.txt --prefix=$HOME/development/rtems/4.11 4.11/rtems-sparc" the execution get stuck building: expat-2.1.0-x86_64-w64-mingw32-1 The following errors are indicated in config.log: gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated. gcc: error: unrecognized command line option '-qversion' gcc: fatal error: no input files compilation terminated.

Or1k bsp not supported for c++ usage

When ENABLE_RTEMS_CXX=yes, or1k build does not work properly.

In file included from ../../../../../rtems/c/src/librtems++/src/rtemsInterrupt.cc:19:0: ../../.././or1ksim/lib/include/rtems++/rtemsInterrupt.h:96:1: error: expected '}' at end of input

}

gmake[3]: * [src/librtems_a-rtemsInterrupt.o] Error 1 gmake[3]: * Waiting for unfinished jobs.... ../../../../../rtems/c/src/librtems++/src/rtemsStatusCode.cc:74:1: error: expected '}' at end of input

}

gmake[3]: * [src/librtems_a-rtemsStatusCode.o] Error 1 gmake[3]: * [src/librtems_a-rtemsEvent.o] Error 1 gmake[3]: * [src/librtems_a-rtemsTimer.o] Error 1 ../../../../../rtems/c/src/librtems++/src/rtemsSemaphore.cc:173:1: error: expected '}' at end of input

}

gmake[3]: * [src/librtems_a-rtemsSemaphore.o] Error 1 gmake[3]: * [src/librtems_a-rtemsMessageQueue.o] Error 1 ../../../../../rtems/c/src/librtems++/src/rtemsTask.cc: In member function 'const rtems_status_code rtemsTask::get_note(uint32_t, uint32_t&)': ../../../../../rtems/c/src/librtems++/src/rtemsTask.cc:269:26: warning: 'rtems_status_code rtems_task_get_note(rtems_id, uint32_t, uint32_t*)' is deprecated (declared at ../../.././or1ksim/lib/include/rtems/rtems/tasks.h:286) [-Wdeprecated-declarations]

}

gmake[3]: * [src/librtems_a-rtemsTask.o] Error 1 gmake[3]: Leaving directory `/scratch/git-rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim/librtems++' gmake[2]: * [all-recursive] Error 1 gmake[2]: Leaving directory `/scratch/git-rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c/or1ksim' gmake[1]: * [all-recursive] Error 1 gmake[1]: Leaving directory `/scratch/git-rtems-testing/rtems/build-or1k-or1ksim-rtems/or1k-rtems4.11/c' make: * [all-recursive] Error 1

_CORE_message_queue_Insert_message() not ISR proof

In case the submit type is not CORE_MESSAGE_QUEUE_SEND_REQUEST or CORE_MESSAGE_QUEUE_URGENT_REQUEST, then we insert the message in priority order. The linear search is not atomic, thus message insertions by higher priority interrupts will corrupt it.

rtemstools cannot be built by RSB under MinGW32

I want to built the Toolchain for RTEMS on Windows 7 SP1 (32 bit with MinGW32/MSYS2), but that fails during built of the RTEMS tools. The build environment has been setup as the documentation of the RTEMS Source Builder suggests.

rsb-report-autoconf-2.69-i686-w32-mingw32-1.txt:

RTEMS Tools Project - Source Builder Error Report
 Build: error: building rtH1
 Command Line: ../source-builder/sb-set-builder --log=l-arm.txt --prefix=C:/msys32/opt/rtems-4.11 4.11/rtems-arm
 Python: 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)]
 P:\SW\gitrepo\rtems-source-builder.git/origin/b65c131f2e11e352fde6efa0ec2fe5000dad3a4a-modified
 Windows
Tail of the build log:
script: 56: 
script: 57: export CFLAGS_FOR_TARGET
script: 58: export CXXFLAGS_FOR_TARGET
script: 59: # Set up the path. Put the CXC path first.
script: 60: if test -n "${SB_TMPBINDIR}" ; then
script: 61:  PATH="${SB_TMPBINDIR}:$PATH"
script: 62: fi
script: 63: if test -n "${SB_TMPCXCBINDIR}" ; then
script: 64:  PATH="${SB_TMPCXCBINDIR}:$PATH"
script: 65: fi
script: 66: if test -n "${SB_EXTRAPATH}" ; then
script: 67:  PATH="${SB_EXTRAPATH}:$PATH"
script: 68: fi
script: 69: 
script: 70: 
script: 71: export PATH
script: 72: # Default environment set up.
script: 73: LANG=C
script: 74: export LANG
script: 75: unset DISPLAY || :
script: 76: umask 022
script: 77: cd "/C/Projekte/rtems-source-builder/rtems/build/rtH1"
script: 78: echo "=> rtems-tools-HEAD-1:"
script: 79: echo "==> %prep:"
script: 80: build_top=$(pwd)
script: 81: source_dir_rtems_tools="rtems-tools-HEAD-1"
source setup: rtems-tools-HEAD-1: source rtems-tools -q -D -n rtems-tools-HEAD-1
Creating source directory: sources\git
making dir: C:\Projekte\rtems-source-builder\rtems\sources\git
git: clone: git://git.rtems.org/rtems-tools.git -> sources\git\rtems-tools.git
git: reset: git://git.rtems.org/rtems-tools.git
git: checkout: git://git.rtems.org/rtems-tools.git => master
git: pull: git://git.rtems.org/rtems-tools.git
script: 82: cd /C/Projekte/rtems-source-builder/rtems/build/rtH1
script: 83: ln -s /C/Projekte/rtems-source-builder/rtems/sources/git/rtems-tools.git ${source_dir_rtems_tools}
script: 84: cd rtems-tools-HEAD-1
script: 85: chmod -R a+rX,g-w,o-w .
script: 86: cd ${build_top}
script: 87: SB_CXC="no"
script: 88: echo "==> clean %{buildroot}: ${SB_BUILD_ROOT}"
script: 89: rm -rf ${SB_BUILD_ROOT}
script: 90: /bin/mkdir -p ${SB_BUILD_ROOT}
script: 91: echo "==> %build:"
script: 92: build_top=$(pwd)
script: 93: if test "i686-w32-mingw32" != "i686-w32-mingw32" ; then
script: 94: RT_HOST="-host=i686-w32-mingw32"
script: 95: else
script: 96: RT_HOST=
script: 97: fi
script: 98: cd ${source_dir_rtems_tools}
script: 99: ./waf configure ${RT_HOST} --prefix=/C/msys32/opt/rtems-4.11
script:100: ./waf
script:101: cd ${build_top}
script:102: echo "==> %install:"
script:103: build_top=$(pwd)
script:104: rm -rf $SB_BUILD_ROOT
script:105: cd ${source_dir_rtems_tools}
script:106: ./waf --destdir=$SB_BUILD_ROOT install
script:107: cd ${build_top}
script:108: echo "==> %clean:"
removing: C:\Projekte\rtems-source-builder\rtems\build\rtH1
making dir: C:\Projekte\rtems-source-builder\rtems\build\rtH1
write script: /C/Projekte/rtems-source-builder/rtems/build/rtH1/doit
building: rtems-tools-HEAD-1
run: sh -ex  /C/Projekte/rtems-source-builder/rtems/build/rtH1/doit
+ export 'SB_ORIG_PATH=/mingw32/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/Python27:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/opt/rtems-4.11/bin:/c/opt/gdc/bin:/c/opt/arm-gdcproject-linux-gnueabi/bin:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/c/Program Files/TortoiseGit/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
+ SB_ORIG_PATH='/mingw32/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/Python27:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/opt/rtems-4.11/bin:/c/opt/gdc/bin:/c/opt/arm-gdcproject-linux-gnueabi/bin:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/c/Program Files/TortoiseGit/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
+ SB_PREFIX=/C/msys32/opt/rtems-4.11
++ echo /C/msys32/opt/rtems-4.11
++ sed -e 's/^\///'
+ SB_PREFIX_CLEAN=C/msys32/opt/rtems-4.11
+ SB_SOURCE_DIR=/C/Projekte/rtems-source-builder/rtems/sources
+ SB_BUILD_DIR=/C/Projekte/rtems-source-builder/rtems/build/rtH1
+ SB_HOST_CFLAGS='-O2 -pipe '
+ SB_HOST_CXXFLAGS='-O2 -pipe '
+ SB_HOST_LDFLAGS=-L/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/lib
+ SB_BUILD_CFLAGS='-O2 -pipe -I/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/include'
+ SB_BUILD_CXXFLAGS='-O2 -pipe -I/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/include'
+ SB_BUILD_LDFLAGS=-L/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/lib
+ SB_CFLAGS='-O2 -pipe -I/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/include '
+ SB_CXXFLAGS='-O2 -pipe -I/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/include '
+ SB_ARCH=i686
+ SB_OS=win32
+ export SB_SOURCE_DIR SB_BUILD_DIR SB_ARCH SB_OS
+ export SB_HOST_CFLAGS SB_HOST_CXXFLAGS SB_HOST_LDFLAGS
+ export SB_BUILD_CFLAGS SB_BUILD_CXXFLAGS SB_BUILD_LDFLAGS
+ export SB_CFLAGS SB_CXXFLAGS
+ SB_DOC_DIR=/C/msys32/opt/rtems-4.11/share/doc
+ export SB_DOC_DIR
+ SB_PACKAGE_NAME=rtems-tools-HEAD-1
+ SB_PACKAGE_BUILDNAME=rtH1
+ SB_PACKAGE_VERSION=HEAD
+ SB_PACKAGE_RELEASE=1
+ export SB_PACKAGE_NAME SB_PACKAGE_VERSION SB_PACKAGE_RELEASE
+ export SB_PREFIX
+ SB_BUILD_DIR=/C/Projekte/rtems-source-builder/rtems/build/rtH1
+ SB_BUILD_ROOT=/C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion
+ SB_BUILD_ROOT_BINDIR=/C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion/C/msys32/opt/rtems-4.11/bin
+ export SB_BUILD_ROOT SB_BUILD_DIR SB_BUILD_ROOT_BINDIR
+ SB_BUILD_CXC_DIR=/C/Projekte/rtems-source-builder/rtems/build/rtH1-cxc
+ SB_BUILD_CXC_ROOT=/C/Projekte/rtems-source-builder/rtems/build/tmp/rtH1-produktion-cxc
+ SB_BUILD_CXC_ROOT_BINDIR=/C/Projekte/rtems-source-builder/rtems/build/tmp/rtH1-produktion-cxc/C/msys32/opt/rtems-4.11/bin
+ export SB_BUILD_CXC_ROOT SB_BUILD_CXC_DIR SB_BUILD_CXC_ROOT_BINDIR
+ SB_TMPROOT=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm
+ SB_TMPPREFIX=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11
+ SB_TMPBINDIR=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin
+ export SB_TMPROOT SB_TMPPREFIX SB_TMPBINDIR
+ SB_TMPCXCROOT=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm
+ SB_TMPCXCPREFIX=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion-cxc/4.11/rtems-arm/C/msys32/opt/rtems-4.11
+ SB_TMPCXCBINDIR=/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion-cxc/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin
+ export SB_TMPCXCROOT SB_TMPCXCPREFIX SB_TMPCXCBINDIR
+ SB_EXTRAPATH=/C/Projekte/rtems-source-builder/source-builder
+ export CFLAGS_FOR_TARGET
+ export CXXFLAGS_FOR_TARGET
+ test -n /C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin
+ PATH='/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin:/mingw32/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/Python27:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/opt/rtems-4.11/bin:/c/opt/gdc/bin:/c/opt/arm-gdcproject-linux-gnueabi/bin:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/c/Program Files/TortoiseGit/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
+ test -n /C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion-cxc/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin
+ PATH='/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion-cxc/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin:/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin:/mingw32/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/Python27:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/opt/rtems-4.11/bin:/c/opt/gdc/bin:/c/opt/arm-gdcproject-linux-gnueabi/bin:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/c/Program Files/TortoiseGit/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
+ test -n /C/Projekte/rtems-source-builder/source-builder
+ PATH='/C/Projekte/rtems-source-builder/source-builder:/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion-cxc/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin:/C/Projekte/rtems-source-builder/rtems/build/tmp/sb-produktion/4.11/rtems-arm/C/msys32/opt/rtems-4.11/bin:/mingw32/bin:/usr/local/bin:/usr/bin:/usr/bin:/c/Python27:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/opt/rtems-4.11/bin:/c/opt/gdc/bin:/c/opt/arm-gdcproject-linux-gnueabi/bin:/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/c/Program Files/TortoiseGit/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
+ export PATH
+ LANG=C
+ export LANG
+ unset DISPLAY
+ umask 022
+ cd /C/Projekte/rtems-source-builder/rtems/build/rtH1
+ echo '=> rtems-tools-HEAD-1:'
+ echo '==> %prep:'
=> rtems-tools-HEAD-1:
==> %prep:
++ pwd
+ build_top=/C/Projekte/rtems-source-builder/rtems/build/rtH1
+ source_dir_rtems_tools=rtems-tools-HEAD-1
+ cd /C/Projekte/rtems-source-builder/rtems/build/rtH1
+ ln -s /C/Projekte/rtems-source-builder/rtems/sources/git/rtems-tools.git rtems-tools-HEAD-1
+ cd rtems-tools-HEAD-1
+ chmod -R a+rX,g-w,o-w .
+ cd /C/Projekte/rtems-source-builder/rtems/build/rtH1
+ SB_CXC=no
+ echo '==> clean %{buildroot}: /C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion'
==> clean %{buildroot}: /C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion
+ rm -rf /C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion
+ /bin/mkdir -p /C/Projekte/rtems-source-builder/rtems/build/tmp/rtems-tools-HEAD-1-root-produktion
+ echo '==> %build:'
==> %build:
++ pwd
+ build_top=/C/Projekte/rtems-source-builder/rtems/build/rtH1
+ test i686-w32-mingw32 '!=' i686-w32-mingw32
+ RT_HOST=
+ cd rtems-tools-HEAD-1
+ ./waf configure --prefix=/C/msys32/opt/rtems-4.11
Setting top to                           : C:\Projekte\rtems-source-builder\rtems\build\rtH1\rtems-tools-HEAD-1 
Setting out to                           : C:\Projekte\rtems-source-builder\rtems\build\rtH1\rtems-tools-HEAD-1\build 
Checking for 'msvc' (C compiler)         : c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\CL.exe 
Checking for 'msvc' (C++ compiler)       : c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\CL.exe 
Checking for header alloca.h             : not found 
Checking for header fcntl.h              : yes 
Checking for header process.h            : yes 
Checking for header stdlib.h             : yes 
Checking for header string.h             : yes 
Checking for header strings.h            : not found 
Checking for header sys/file.h           : not found 
Checking for header sys/stat.h           : yes 
Checking for header sys/time.h           : not found 
Checking for header sys/types.h          : yes 
Checking for header sys/wait.h           : not found 
Checking for header unistd.h             : not found 
Checking for header vfork.h              : not found 
Checking for function getrusage          : not found 
Checking for header sys/wait.h           : not found 
Checking for function kill               : not found 
Checking for function open64             : not found 
Checking for function stat64             : not found 
Checking for program 'python'            : C:\Python27\python.exe 
Checking for python version              : (2, 7, 9, 'final', 0) 
Checking for python version              : (2, 7, 9, 'final', 0) 
'configure' finished successfully (2.803s)
+ ./waf
Waf: Entering directory `C:\Projekte\rtems-source-builder\rtems\build\rtH1\rtems-tools-HEAD-1\build'
[  1/236] Compiling rtemstoolkit\elftoolchain\libelf\libelf_convert.m4
[  2/236] Compiling rtemstoolkit\elftoolchain\libelf\libelf_fsize.m4
[  3/236] Compiling rtemstoolkit\elftoolchain\libelf\libelf_msize.m4
[  4/236] Compiling rtemstoolkit\elftoolchain\libelf\elf.c
elf.c

c:\projekte\rtems-source-builder\rtems\build\rth1\rtems-tools-head-1\rtemstoolkit\elftoolchain\libelf\libelf.h(32) : fatal error C1083: Datei (Include) kann nicht ge”ffnet werden: "sys/param.h": No such file or directory


cl : Befehlszeile warning D9002 : Unbekannte Option "-pipe" wird ignoriert.

cl : Befehlszeile warning D9002 : Unbekannte Option "-g" wird ignoriert.


Waf: Leaving directory `C:\Projekte\rtems-source-builder\rtems\build\rtH1\rtems-tools-HEAD-1\build'
Build failed
 -> task in 'elf' failed (exit status 2): 
	{task 26199408: c elf.c -> elf.c.4.o}
['c:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\BIN\\CL.exe', '/nologo', '-pipe', '-g', '-O2', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\build', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\build\\rtemstoolkit\\elftoolchain\\libelf', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\rtemstoolkit\\elftoolchain\\libelf', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\build\\rtemstoolkit\\elftoolchain\\common', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\rtemstoolkit\\elftoolchain\\common', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\build\\rtemstoolkit\\win32', '/IC:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\rtemstoolkit\\win32', '/Ic:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\INCLUDE', '/Ic:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\ATLMFC\\INCLUDE', '/Ic:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\include', '/DPYTHONDIR="C:\\Python27\\Lib\\site-packages"', '/DPYTHONARCHDIR="C:\\Python27\\Lib\\site-packages"', '', '..\\rtemstoolkit\\elftoolchain\\libelf\\elf.c', '/FC', '/c', '/Fo', 'C:\\Projekte\\rtems-source-builder\\rtems\\build\\rtH1\\rtems-tools-HEAD-1\\build\\rtemstoolkit\\elftoolchain\\libelf\\elf.c.4.o']
shell cmd failed: sh -ex  /C/Projekte/rtems-source-builder/rtems/build/rtH1/doit
error: building rtH1

BSP spec file error.

The BSP specs files have an error. See the devel list thread ​https://lists.rtems.org/pipermail/devel/2015-May/011256.html for details.

Interrupt latency problem in _POSIX_Timer_Insert_helper()

Interrupts are disabled arround a _Watchdog_Insert() in _POSIX_Timer_Insert_helper().

rtems_waf: Install is broken for version != 4.11

"waf install" is broken for version != 4.11 due to use of hard-coded

default_version = '4.11'

in rtems.py.

WorkSpace? wiki page

A page named 'WorkSpace?' is referenced from ​https://devel.rtems.org/wiki/Debugging/Start, although the links are dead. I'm not sure whether there is supposed to be an actual page on 'WorkSpace?', or if this is just caused by WikiFormatting.

RTEMSReferences automatically deleting content

I've looked through the diff's for changes made to ​https://devel.rtems.org/wiki/TBR/Website/RTEMSReferences and the page is repeatedly deleting content from the bottom of the page as more references are added. This is most likely due to the page reaching maximum page size as different versions had around the same character count (64800~) as plain text. According to ​http://trac.edgewall.org/wiki/TracIni this size can be configured from the trac.ini file, with the [wiki] max_size variable. Another alternative is to create a seperate page for each year so that it doesn't exceed the size limit.

RSB Python scripts may refer to Python3

The RSB python scripts all have the same shebang line:

#!/usr/bin/env python

However, on certain systems, most notably Arch Linux, the default python environment is Python3. This causes all the RSB scripts to fail. Instead, a simple approach would be to explicitly invoke the Python2 environment. All systems that ship only Python2 also have the python2 symlink.

I've attached patch I made by changing all the shebang lines to python2. With these changes, I am still unable to completely build the SPARC tools on my machine. Some more Python related issues it seems. I shall debug those and either ask for further help later, or provide a patch Do let me know if anything else is required.

Shell: printf() format specifiers do not match parameter types

e.g.:

(void)snprintf(buf, sizeof(buf), "%llu", (long long)howmany(maxblock, blocksize));

Add per-section compilation and linking support to powerpc/motorola_powerpc

As per #2577, per-section compilation and linking support should be added to this BSP. Since it uses the powerpc shared linker script, this only needs to have the necessary optimisations added.

Update POSIX 1003.1 Compliance Guide

Update the POSIX 1003.1 Compliance Guide to REST format.

Update Filesystem Design Guide

Update the Filesystem Design Guide to REST format.

MSDOS_MAX_DIR_LENGHT typo

MSDOS_MAX_DIR_LENGHT -> MSDOS_MAX_DIR_LENGTH

$ ack LENGHT
msdos.h
239:#define MSDOS_MAX_DIR_LENGHT               0x200000   /* 2,097,152 bytes */

msdos_create.c
193:        fat_fd->size_limit = MSDOS_MAX_DIR_LENGHT;

msdos_initsupp.c
100:    fat_fd->size_limit = MSDOS_MAX_DIR_LENGHT;

msdos_misc.c
391:            fat_fd->size_limit = MSDOS_MAX_DIR_LENGHT;
584:    fat_fd->size_limit = MSDOS_MAX_DIR_LENGHT;
653:    fat_fd->size_limit = MSDOS_MAX_DIR_LENGHT;

P.S. Goes unnoticed since original 2002 commit.

Enhancement for more general real-time model

In the current implementation, if a task period is time out, the next call of rtems_rate_monotonic_period() will only release one following job and manipulate the task period with the calling moment + the next length of period. With the assumption that implicit/constraint deadline and hard real-time model, the above mechanism is okay.

However, it is not applicable for more general task models, e.g., soft real-time task, arbitrary deadline, mixed-criticality system [1-4]. It is in fact changing the behaviour of periodic/sporadic tasks, where the task period becomes unpredictable and shifted . Also, there maybe more than one postponed instances due to the preemption.

Although there is no standard requirement in reality for deadline misses, with this enhancement, the postponed jobs will be released with the correct number without shifting the periodicity of tasks. In fact, this way of handling is already widely considered in academia from 90s [2] until now [3] or even on multicores as well [4].

I refine the following four files and handle this requirement individually. The overhead seems to me negligible. cpukit/rtems/include/rtems/rtems/ratemon.h cpukit/rtems/include/rtems/rtems/ratemonimpl.h cpukit/rtems/src/ratemontimeout.c cpukit/rtems/src/ratemonperiod.c

I believe this patch is good for further use in more general real-time task models. This enhancement only affect those timeout cases without changing any behaviour in normal cases. To demonstrate the differences, a heuristic example is prepared in testsuites/sptests/sprmsched01 to show the benefit of the enhancement:

Given two tasks with implicit deadline that task deadline is equal to its period. Task 1 period is 10000 ticks, whereas task 2 is 2000 ticks. Task 1 has the execution time 6000 ticks, and task 2 has 1000 ticks. Assume Task 1 has a higher priority than task 2. Task 1 only executes 2 times. In the expected result, we can observe that the postponed jobs are continuously released till there is no postponed job left, and the task period will still keep as it is. (Job 3-7 in task 2 are postponed jobs)

[1] Buttazzo et al., Soft Real-Time Systems: Predictability vs. Efficiency, Springer 2005, ​http://www.springer.com/gp/book/9780387237015 [2] Lehoczky et al., Fixed priority scheduling of periodic task sets with arbitrary deadlines, RTSS 1990, ​http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=128748 [3] Georg von der Brüggen et al., Systems with Dynamic Real-Time Guarantees in Uncertain and Faulty Execution Environments, RTSS'16, accepted. [4] Huang et al., Response time bounds for sporadic arbitrary-deadline tasks under global fixed-priority scheduling on multiprocessors, RTNS 2015, ​http://dl.acm.org/citation.cfm?doid=2597457.2597459