Build failure on RTEMS 4.10.2

[Andrew Johnson]

Michael Westfall reported:

When compiling base R3.14.12.7 for RTEMS 4.10.2, I get the following error:

/gem_swdev1/targetOS/RTEMS/rtems-4.10/bin/powerpc-rtems4.10-gcc --pipe -B/gem_swdev1/targetOS/RTEMS/rtems-4.10/powerpc-rtems4.10/beatnik/lib/ -specs bsp_specs -qrtems -fasm -c -mcpu=7400 -D__ppc_generic -DUNIX -O2 -g -g -Wall -DMY_DO_BOOTP=NULL -DHAVE_MOTLOAD -DRTEMS_NETWORK_CONFIG_MBUF_SPACE=2048 -DRTEMS_NETWORK_CONFIG_CLUSTER_SPACE=5120 -MMD -I. -I../O.Common -I. -I../../../src/libCom/osi/os/RTEMS -I../../../src/libCom/osi/os/posix -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/bucketLib -I../../../src/libCom/ring -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh -I../../../src/libCom/logClient -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCom/tsDefs -I/gem_swdev1/epics/R3.14.12.7/base/include/os/RTEMS -I/gem_swdev1/epics/R3.14.12.7/base/include ../../../src/libCom/osi/os/RTEMS/osdThread.c
../../../src/libCom/osi/os/RTEMS/osdThread.c: In function 'showInternalTaskInfo':
../../../src/libCom/osi/os/RTEMS/osdThread.c:617: error: 'Thread_Control' has no member named 'real_priority'
../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'current_priority'
../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'real_priority'
../../../src/libCom/osi/os/RTEMS/osdThread.c:625: error: 'Thread_Control' has no member named 'current_priority'
../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'real_priority'
../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'current_priority'
make[3]: *** [osdThread.o] Error 1

[mdavidsaver (mdavidsaver)]

Heinz has a fix.

https://epics.anl.gov/tech-talk/2019/msg00083.php

Needs to confirm this with older RTEMS.

[Andrew Johnson (anj)]

Did this bug fall through the cracks?

[Andrew Johnson (anj)]

I finally took a proper look at this bug report.

The APS has been using RTEMS 4.10.2 since 2013 (4.10.2 was tagged on 2011-12-13, I built it in December 2012) and our headers do *not* have this change, which was committed to the 4.10 branch of RTEMS in December 2017 (78b867e26d score: replace current and real priority with priority node).

Merging this particular change would thus break EPICS builds here at APS, and unfortunately it doesn't look like there's an easy way to detect the change at compile-time. Until someone can work out how to do that I can't accept this patch into the Base 3.15 or 7.0 branches.

[Heinz Junkes (junkes)]

Ok, I would now try to replace the "internal" direct accesses with API accesses (advice of the RTEMS developers).
Current_priority can be read with: rtems_task_set_priority
The real_priority can be read with a pthread call : pthread_getschedparam
I guess that the BSP has to be generated with --enable-posix.
The question to Andrew: Did the BSPs at APS used to be created with --enable-posix?

Here are my intended calls:

diff --git a/src/libCom/osi/os/RTEMS/osdThread.c b/src/libCom/osi/os/RTEMS/osdThread.c
index c19279ecf..ebeabfa6b 100644
--- a/src/libCom/osi/os/RTEMS/osdThread.c
+++ b/src/libCom/osi/os/RTEMS/osdThread.c
@@ -39,6 +39,8 @@
#include "osdInterrupt.h"
#include "epicsExit.h"

+#include <pthread.h>
+
epicsShareFunc void osdThreadHooksRun(epicsThreadId id);
epicsShareFunc void osdThreadHooksRunMain(epicsThreadId id);

@@ -622,6 +624,26 @@ showInternalTaskInfo (rtems_id tid)
     * that priority should be displayed, not the value truncated to
     * the EPICS range.
     */
+ /* one should not use "internal" RTEMS structures
+ * only calls by API should be used */
+ rtems_status_code sc;
+
+ rtems_task_priority myCurrentPrio, myRealPrio;
+ struct sched_param sp;
+ int policy;
+
+ sc = pthread_getschedparam(tid, &policy, &sp);
+ if (sc != 0) {
+ fprintf(epicsGetStdout(),"%-30s", " *** RTEMS task gone! ***");
+ return;
+ }
+ myRealPrio = sp.sched_priority;
+ sc = rtems_task_set_priority(tid,0,&myCurrentPrio);
+ if (sc != 0) {
+ fprintf(epicsGetStdout(),"%-30s", " *** RTEMS task gone! ***");
+ return;
+ }
+
    epicsPri = 199-thread.real_priority;
    if (epicsPri < 0)
        fprintf(epicsGetStdout()," <0");

[Andrew Johnson (anj)]

They do have a pthread.h header, and I was able to build 3.15 for the uC5282 target with calls to those APIs added to the osdThread.c file (I didn't apply your patch in full but I did add the calls to pthread_getschedparam() and rtems_task_set_priority() plus the supporting declarations). The build reconstructed all the bootable test harnesses, and the .boot files are all about 200 bytes larger, so doing this isn't pulling in lots of additional code.

I don't think you meant the above diff to be the final set of changes since the code below your additions is still accessing the internal structures instead of using the values you're looking up, but I believe this approach will work.

I don't have the ability to actually run the result, but I'll be willing to apply a patch using this approach without doing that. If you can produce it in the next couple of days I can probably still get it into the 3.15.8 release.

Thanks.

[mdavidsaver (mdavidsaver)]

> unfortunately it doesn't look like there's an easy way to detect the change at compile-time

In fact there is. This (internal) API change appears on the RTEMS 4.10 branch after the (latest) 4.10.2 release.

I've been testing the attached patch for the past week or so.

[mdavidsaver (mdavidsaver)]

> --enable-posix

I've seen this, but never had reason to include it.
Shouldn't be difficult. At least once I get the toolchain rebuilt.

> download: ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.3.2/gcc-core-4.3.2.tar.bz2: error: [Errno ftp error] 425 Security: Bad IP connecting.

sigh... Apparently gnu.org is at war with travis-ci.org tonight.

https://travis-ci.org/github/mdavidsaver/rsb

[Heinz Junkes (junkes)]

I have now replaced the accesses to the internal thread structure (real_priority, current_priority) with API - calls. One of the calls is from the pthread-library and therefore needs --enable-posix when creating the BSP.
Calls used
pthread_getschedparam
rtems_task_set_priority

I tried it with Epics 3.15 and 7. Unfortunately I couldn't get it to try it with qemu-system-i386. I always failed at network initialization.

Unfortunately I lost the thread how to use the qemu-system-i386 emulator for Epics 7. I missed .ci/travis-build ...

[Ralph Lange (ralph-lange)]

Well, .ci/travis-build is now .ci/travis/build ...

[Ralph Lange (ralph-lange)]

Admittedly, most of the logic has been moved to .ci/travis/utils

[Andrew Johnson (anj)]

Michael, I see 2 issues with your patch:

1. It seems to be missing __RTEMS_REVISION__ in RTEMS_VERSION_INT value, so as shown none of the 4.10.x releases would make that version comparison true, although 4.11 releases would. As a result I suspect it would fail in Mike Westfall's environment.

2. You appear to have completely misunderstood the problem with detecting this change at compile-time; I was talking about the fact that both my RTEMS build and Mike's report themselves as being 4.10.2, yet we are on different sides of the structure change. AFAIK there have been no releases or version number bumps on the 4.10 branch since they made the change, so our code can't use the version number to tell the two apart:

tux% git log VERSION
commit 0ae9ee1da48d7deab49e42aa789ba02de8501047 (tag: 4.10.2)
Author: Joel Sherrill <email address hidden>
Date: Tue Dec 13 14:34:19 2011 +0000

    Upgrade to 4.10.2

I haven't looked at it yet but I suspect Heinz' patch will be much more useful; I will take a look at it after my group meeting.

[Heinz Junkes (junkes)]

Hmm,

git clone https://github.com/epics-base/epics-base.git

[h1@earth BUG_FIX_4_10_2]$ cd epics-base
[h1@earth epics-base (7.0 *)]$ ls -la .ci/
total 8
drwxrwxr-x 2 h1 h1 4096 May 13 16:24 .
drwxrwxr-x 19 h1 h1 4096 May 13 17:06 ..

On 2020-05-13 17:23, Ralph Lange wrote:
> Well, .ci/travis-build is now .ci/travis/build ...
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1812084
>

[mdavidsaver (mdavidsaver)]

Ok, never mind. I admit I gave up on the 4.10 branch some time ago. I was assuming that RTEMS followed the usual practice of incrementing the version immediately after a release.

[mdavidsaver (mdavidsaver)]

RSB seems to default to '--enable-posix' so it looks like the toolchains used by travis-ci already include libposix.a. (which is good since I've quickly realized that I have no idea how to ask RSB to set it)

[Ralph Lange (ralph-lange)]

> Hmm,

> git clone https://github.com/epics-base/epics-base.git

As ci-scripts is a git submodule, you have to either 'clone --recursive' or do a 'submodule init' and 'submodule update'.

https://git-scm.com/book/en/v2/Git-Tools-Submodules

[Ralph Lange (ralph-lange)]

Note that for software development and local builds you don't need the .ci submodule, so not checking it out is still a reasonable default.

As an alternative to looking at the local files, you can always look at ci-scripts online.
https://github.com/epics-base/ci-scripts

The README files are complete and up-to-date.

[mdavidsaver (mdavidsaver)]

> Unfortunately I lost the thread how to use the qemu-system-i386 emulator

If you're building for the RTEMS-pc386-qemu target, it should be as simple as 'make runtests'.

The specific incantation is found in makeTestfile.pl, and the individual .t files after a build.

https://github.com/epics-base/epics-base/blob/7.0/src/tools/makeTestfile.pl#L41

At the moment this is

qemu-system-i386 -m 64 -no-reboot \
 -serial stdio -display none \
 -net nic,model=ne2k_pci -net user,restrict=yes \
 -kernel $exe

[Andrew Johnson (anj)]

That might not be true for 3.15 which is where Heinz is working; I only build the RTEMS qemu target on my 7.0 branch, so I'm not sure.

I applied his latest patch to my 3.15 branch and my uC5282 target built successfully. I then manually applied it to the 7.0 branch and it builds successfully there too. Of course the change itself is in a routine that is called from epicsThreadShow() so we don't have a test for it. I added a call to the end of MAIN() in epicsThreadTest.cpp and it seemed to work on the qemu target:

 0a010001 52 147/108 RUN _main_

I'm happy to apply a version of this patch to 3.15, any objections?

[Heinz Junkes (junkes)]

Thanks for all your information.

I did exactly the same thing this afternoon. It just kept getting stuck
somewhere. Now I've taken the commands
from the history and now it works (in Epics 7 ayt least)?

in epics 7 :

qemu-system-i386 -m 64 -no-reboot -serial stdio -display none -net
nic,model=ne2k_pci -net user,restrict=yes -kernel libComTestHarness

     EPICS Test Harness Results
     ==========================

All tests successful.
Programs=37, Tests=3046, 234 wallclock secs

ok 2 - counter() called once
ok 3 - unregistered counter() not called
ok 4 - Registered mainExit()
# threadA starting
ok 5 - Registered atExit(0x34d780)
ok 6 - Registered atThreadExit(0x34d780)
# threadA waiting for atExit
# threadB starting
ok 7 - Registered atExit(0x34d7d0)
ok 8 - Registered atThreadExit(0x34d7d0)
# threadB waiting for atExit
# Calling epicsExit
ok 9 - threadB reached atExit
ok 10 - threadB terminating
ok 11 - threadB destroying pinfo
ok 12 - threadA reached atExit
ok 13 - threadA terminating
ok 14 - threadA destroying pinfo
ok 15 - Reached mainExit

     Results
     =======
        Tests: 15
       Passed: 15 = 100.00%

Epics 3.15 there is no rtems-pc368-qemu, I made it with
make -j2 RTEMS_QEMU_FIXUPS=YES

calling
qemu-system-i386 -m 64 -no-reboot -serial stdio -display none -net
nic,model=ne2k_pci -net user,restrict=yes -kernel libComTestHarness

is stuck, now output, no progress,

without "-display none" see Screenshot.

Danke, Heinz

On 2020-05-13 19:27, mdavidsaver wrote:
>> Unfortunately I lost the thread how to use the qemu-system-i386
> emulator
>
> If you're building for the RTEMS-pc386-qemu target, it should be as
> simple as 'make runtests'.
>
> The specific incantation is found in makeTestfile.pl, and the
> individual
> .t files after a build.
>
> https://github.com/epics-base/epics-
> base/blob/7.0/src/tools/makeTestfile.pl#L41
>
> At the moment this is
>
> qemu-system-i386 -m 64 -no-reboot \
> -serial stdio -display none \
> -net nic,model=ne2k_pci -net user,restrict=yes \
> -kernel $exe
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1812084
>
> Title:
> Build failure on RTEMS 4.10.2
>
> Status in EPICS Base:
> Confirmed
> Status in EPICS Base 3.15 series:
> Confirmed
> Status in EPICS Base 7.0 series:
> Confirmed
>
> Bug description:
> Michael Westfall reported:
>
> When compiling base R3.14.12.7 for RTEMS 4.10.2, I get the following
> error:
>
> /gem_swdev1/targetOS/RTEMS/rtems-4.10/bin/powerpc-rtems4.10-gcc
> --pipe
> -B/gem_swdev1/targetOS/RTEMS/rtems-4.10/powerpc-rtems4.10/beatnik/lib/
> -specs bsp_specs -qrtems -fasm -c -mcpu=7400 -D__ppc_generic
> -DUNIX -O2 -g -g -Wall -DMY_DO_BOOTP=NULL
> -DHAVE_MOTLOAD -DRTEMS_NETWORK_CONFIG_MBUF_SPACE=2048
> -DRTEMS_NETWORK_CONFIG_CLUSTER_SPACE=5120 -MMD -I. -I../O.Common
> -I. -I../../../src/libCom/osi/os/RTEMS
> -I../../../src/libCom/osi/os/posix
> -I../../../src/libCom/osi/os/default -I..
> -I../../../src/libCom/bucketLib -I../../../src/libCom/ring
> -I../../../src/libCom/calc -I../../../src/libCom/cvtFast
> -I../../../src/libCom/cppStd -I../../../...

[mdavidsaver (mdavidsaver)]

Looks like you need to do a 'make distclean' and rebuild with RTEMS_QEMU_FIXUPS=YES. Console redirection is one of the things which RTEMS_QEMU_FIXUPS=YES is changing.

[Andrew Johnson (anj)]

I just merged a slightly modified version of this patch, removing the duplicate error path.

Thanks Heinz.

[Heinz Junkes (junkes)]

RTEMS_QEMU_FIXUPS does not occur in 3.15 ;-)

Heinz

> On 13. May 2020, at 21:11, mdavidsaver <email address hidden> wrote:
>
> Looks like you need to do a 'make distclean' and rebuild with
> RTEMS_QEMU_FIXUPS=YES. Console redirection is one of the things which
> RTEMS_QEMU_FIXUPS=YES is changing.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1812084
>
> Title:
> Build failure on RTEMS 4.10.2
>
> Status in EPICS Base:
> Confirmed
> Status in EPICS Base 3.15 series:
> Confirmed
> Status in EPICS Base 7.0 series:
> Confirmed
>
> Bug description:
> Michael Westfall reported:
>
> When compiling base R3.14.12.7 for RTEMS 4.10.2, I get the following
> error:
>
> /gem_swdev1/targetOS/RTEMS/rtems-4.10/bin/powerpc-rtems4.10-gcc --pipe -B/gem_swdev1/targetOS/RTEMS/rtems-4.10/powerpc-rtems4.10/beatnik/lib/ -specs bsp_specs -qrtems -fasm -c -mcpu=7400 -D__ppc_generic -DUNIX -O2 -g -g -Wall -DMY_DO_BOOTP=NULL -DHAVE_MOTLOAD -DRTEMS_NETWORK_CONFIG_MBUF_SPACE=2048 -DRTEMS_NETWORK_CONFIG_CLUSTER_SPACE=5120 -MMD -I. -I../O.Common -I. -I../../../src/libCom/osi/os/RTEMS -I../../../src/libCom/osi/os/posix -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/bucketLib -I../../../src/libCom/ring -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh -I../../../src/libCom/logClient -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCom/tsDefs -I/gem_swdev1/epics/R3.14.12.7/base/include/os/RTEMS -I/gem_swdev1/epics/R3.14.12.7/base/include ../../../src/libCom/osi/os/RTEMS/osdThread.c
> ../../../src/libCom/osi/os/RTEMS/osdThread.c: In function 'showInternalTaskInfo':
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:617: error: 'Thread_Control' has no member named 'real_priority'
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'current_priority'
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:624: error: 'Thread_Control' has no member named 'real_priority'
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:625: error: 'Thread_Control' has no member named 'current_priority'
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'real_priority'
> ../../../src/libCom/osi/os/RTEMS/osdThread.c:627: error: 'Thread_Control' has no member named 'current_priority'
> make[3]: *** [osdThread.o] Error 1
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/epics-base/+bug/1812084/+subscriptions

[Ralph Lange (ralph-lange)]

Was introduced in 3.16.2, IIRC.
(https://code.launchpad.net/~epics-core/epics-base/test-rtems-w-qemu/+merge/286116)

[mdavidsaver (mdavidsaver)]

> RTEMS_QEMU_FIXUPS does not occur in 3.15 ;-)

Sorry guys. There is only so much I can do when you are working with 3.15.