[PATCH] gdb: prefere python3 if it is installed
More and more systems stop shipping python2. So we should start to
prefer python3 over python2. For building gdb it is not only necessary
to have a python binary installed, but also the matching python-devel
packet. On a lot of hosts that will now be more often python3-devel
and not python2-devel.
---
Note: Please see that patch more as an suggestion / base for
discussion. I'm open to better solutions.
My problem that triggered this patch was a build of a toolchain on a
github CI/CD system that has been originally set up by one of our
users (see [1] for the log). It seems that on the "macos-latest"
machines a python2 is installed but no python2 headers are found.
Homebrew - which could be used earlier on MacOS to install the
necessary headers - dropped the python@2 packet. So it seems that on a
modern MacOS there is no possibility to get python2 headers. If
python2 is still installed on the machine (for whatever reason), it is
not possible to successfully use RTEMS source builder to build a gdb.
If python3 is preferred instead, that should solve the problem.
Note that at the moment I only tried it on my OpenSUSE-Linux machine.
For that I made sure that I have python2 and python3 installed but no
python-devel (which is python2 on OpenSUSE). Earlier I know that I
needed python-devel to build gdb. With this patch, I can build with
only python3-devel.
I'll try to add that patch to the CI too to see whether it works on
MacOS. But I'm a bit unsure what other problems this patch could
trigger and therefore I want to start a discussion early.
Best regards
Christian
[1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
Note: The "Get Errorinfo" step prints the rsb-report-*.txt
source-builder/config/gdb-common-1.cfg | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/source-builder/config/gdb-common-1.cfg
b/source-builder/config/gdb-common-1.cfg
index 397d44d..42fe263 100644
--- a/source-builder/config/gdb-common-1.cfg
+++ b/source-builder/config/gdb-common-1.cfg
@@ -42,7 +42,7 @@
# 2. Does the version of gdb specify a version of python that must be
#used. Override with '%define gdb-python-version python2'.
#
-# 3. Search for 'python2' and if not found search for 'python3'.
+# 3. Search for 'python3' and if not found search for 'python2'.
#
%if %{defined gdb-python2}
%define gdb-enable-python %{gdb_python2}
@@ -53,9 +53,9 @@
%if %{defined gdb-python-version}
%define gdb-enable-python %(command -v %{gdb-python-version} || true)
%else
- %define gdb-enable-python %(command -v python2 || true)
+ %define gdb-enable-python %(command -v python3 || true)
%if %{gdb-enable-python} == %{nil}
-%define gdb-enable-python %(command -v python3 || true)
+%define gdb-enable-python %(command -v python2 || true)
%endif
%if %{gdb-enable-python} == %{nil}
%define gdb-enable-python %(command -v python || true})
--
2.31.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
PS: I had the problem on the 5 branch of RTEMS source builder. I think
we should apply a patch to both: master and the 5 branch.
Am 19.08.21 um 10:34 schrieb Christian Mauderer:
More and more systems stop shipping python2. So we should start to
prefer python3 over python2. For building gdb it is not only necessary
to have a python binary installed, but also the matching python-devel
packet. On a lot of hosts that will now be more often python3-devel
and not python2-devel.
---
Note: Please see that patch more as an suggestion / base for
discussion. I'm open to better solutions.
My problem that triggered this patch was a build of a toolchain on a
github CI/CD system that has been originally set up by one of our
users (see [1] for the log). It seems that on the "macos-latest"
machines a python2 is installed but no python2 headers are found.
Homebrew - which could be used earlier on MacOS to install the
necessary headers - dropped the python@2 packet. So it seems that on a
modern MacOS there is no possibility to get python2 headers. If
python2 is still installed on the machine (for whatever reason), it is
not possible to successfully use RTEMS source builder to build a gdb.
If python3 is preferred instead, that should solve the problem.
Note that at the moment I only tried it on my OpenSUSE-Linux machine.
For that I made sure that I have python2 and python3 installed but no
python-devel (which is python2 on OpenSUSE). Earlier I know that I
needed python-devel to build gdb. With this patch, I can build with
only python3-devel.
I'll try to add that patch to the CI too to see whether it works on
MacOS. But I'm a bit unsure what other problems this patch could
trigger and therefore I want to start a discussion early.
Best regards
Christian
[1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
Note: The "Get Errorinfo" step prints the rsb-report-*.txt
source-builder/config/gdb-common-1.cfg | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/source-builder/config/gdb-common-1.cfg
b/source-builder/config/gdb-common-1.cfg
index 397d44d..42fe263 100644
--- a/source-builder/config/gdb-common-1.cfg
+++ b/source-builder/config/gdb-common-1.cfg
@@ -42,7 +42,7 @@
# 2. Does the version of gdb specify a version of python that must be
#used. Override with '%define gdb-python-version python2'.
#
-# 3. Search for 'python2' and if not found search for 'python3'.
+# 3. Search for 'python3' and if not found search for 'python2'.
#
%if %{defined gdb-python2}
%define gdb-enable-python %{gdb_python2}
@@ -53,9 +53,9 @@
%if %{defined gdb-python-version}
%define gdb-enable-python %(command -v %{gdb-python-version} || true)
%else
- %define gdb-enable-python %(command -v python2 || true)
+ %define gdb-enable-python %(command -v python3 || true)
%if %{gdb-enable-python} == %{nil}
-%define gdb-enable-python %(command -v python3 || true)
+%define gdb-enable-python %(command -v python2 || true)
%endif
%if %{gdb-enable-python} == %{nil}
%define gdb-enable-python %(command -v python || true})
--
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Using libbsd dhcpcd options
I'd like to use the DHCP option 17 (Root Path) to get a mount point for NFS
from the DHCP server.
I'm starting dhcp with "rtems_dhcpcd_start(NULL)" so it's starting with only
the argv array of {"dhcpcd", NULL }.
I *think* I need to start it with a customized rtems_dhcpcd_config that would
maybe include a "--option" argument, and retrieve it in a run hook (I'm using
the run hook already to wait for an IP address to be assigned). The FreeBSD
"--option" documentation is:
-o, --option "option"
Request the DHCP "option" variable for use in
"/usr/local/libexec/dhcpcd-run-hooks".
which would be an argv of {"dhcpcd", "--option", "17", NULL }.
Or is best practice to do something with "rtems-bsd-rc-conf-net.c"?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] arm/xilinx: Fix zynq-uart interrupt receive
On 8/18/2021 18:02, Chris Johns wrote: On 19/8/21 5:49 am, Kinsey Moore wrote: On 8/18/2021 13:20, Chris Johns wrote: On 19/8/21 3:41 am, Kinsey Moore wrote: This is functional on the ZynqMP board I currently have setup for testing and on ZynqMP QEMU except for the data corruption/loss caused by the removal of the post-baud-set null write. Thanks for the testing. I am not sure if you are saying both the ZyncMP hardware and qemu need the write or just qemu. The write may work but it does not make sense because at some point the software will print a character and achive the same thing? QEMU works fine either way. The ZynqMP hardware is what has issues without the null write. OK The problem is that it's picky about which characters will actually fix the data loss/corruption. I've seen that both space and null will do it while letters and numbers won't. Null was chosen specifically because it's not printable. It shows up on Zynq consoles I have running a a junk character. Without this null print, I see garbage output and it eventually starts printing text correctly. How many characters? It smells like a clock is hunting. I suggest you ask Joel to raise this with Xilinx to see if there is any known errata. The number varies depending on the text being output. It continues spewing bad characters until it encounters a character that resets whatever internal mechanism is causing this. I'll see if we can get some information from Xilinx. Another suggestion is downloading the Xilinx SDK and looking over the bare metal console support to see what they do there. The sticking point here seems to be baud rate manipulation and the TX/RX reset that must occur. The bare metal driver has code for this, but it is never called as far as I can tell. I still haven't found the startup sequence that initializes the UART, but I'll take another look. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/1] Implementation / tests for pthread_cond_clockwait()
On Wed, Aug 18, 2021 at 8:44 PM Joel Sherrill wrote: > > On Wed, Aug 18, 2021 at 6:17 AM Matt Joyce wrote: > > > > Added implementation of the pthread_cond_clockwait() > > method to cpukit/posix/src/condclockwait.c. Additional > > logic added to condwaitsupp.c to implement new method. > > pthread_cond_clockwait() has been added to the Issue 8 > > POSIX Standard. > > > > psx17 test added to testsuites/psxtests to test the > > newly added method. > > --- > > cpukit/include/rtems/posix/condimpl.h | 1 + > > cpukit/posix/src/condclockwait.c | 69 +++ > > cpukit/posix/src/condtimedwait.c | 1 + > > cpukit/posix/src/condwait.c | 1 + > > cpukit/posix/src/condwaitsupp.c | 64 ++- > > spec/build/testsuites/psxtests/grp.yml| 2 + > > spec/build/testsuites/psxtests/psx17.yml | 20 + > > testsuites/psxtests/Makefile.am | 8 + > > testsuites/psxtests/configure.ac | 1 + > > testsuites/psxtests/psx17/init.c | 425 ++ > > testsuites/psxtests/psx17/psx17.doc | 45 ++ > > testsuites/psxtests/psx17/psx17.scn | 82 > > testsuites/psxtests/psx17/system.h| 57 +++ > > .../psxhdrs/pthread/pthread_cond_clockwait.c | 2 +- > > 14 files changed, 761 insertions(+), 17 deletions(-) > > create mode 100644 cpukit/posix/src/condclockwait.c > > create mode 100644 spec/build/testsuites/psxtests/psx17.yml > > create mode 100644 testsuites/psxtests/psx17/init.c > > create mode 100644 testsuites/psxtests/psx17/psx17.doc > > create mode 100644 testsuites/psxtests/psx17/psx17.scn > > create mode 100644 testsuites/psxtests/psx17/system.h > > > > diff --git a/cpukit/include/rtems/posix/condimpl.h > > b/cpukit/include/rtems/posix/condimpl.h > > index 66e09bf6d8..6efbc3af70 100644 > > --- a/cpukit/include/rtems/posix/condimpl.h > > +++ b/cpukit/include/rtems/posix/condimpl.h > > @@ -152,6 +152,7 @@ int _POSIX_Condition_variables_Signal_support( > > int _POSIX_Condition_variables_Wait_support( > >pthread_cond_t*cond, > >pthread_mutex_t *mutex, > > + clockid_t clock_id, > >const struct timespec *abstime > > The clock_id parameter should be aligned with the rest. I'm having a little trouble with this and the one below: It looks aligned in both vscode and in vim...even when I cat the patch. But here it's clearly misaligned. I went back in and re-aligned all the variables, but I'm still getting this misaligned output. Could you please advise? > > > ); > > > > diff --git a/cpukit/posix/src/condclockwait.c > > b/cpukit/posix/src/condclockwait.c > > new file mode 100644 > > index 00..4104235706 > > --- /dev/null > > +++ b/cpukit/posix/src/condclockwait.c > > @@ -0,0 +1,69 @@ > > +/** > > + * @file > > + * > > + * @ingroup POSIXAPI > > + * > > + * @brief Waiting on a Condition > > + */ > > + > > +/* > > +* Copyright (C) 2021 Matthew Joyce > > General question. Do we have a master list Matthew needs to be added to? > Or is that just documentation? > > > +* > > +* Redistribution and use in source and binary forms, with or without > > +* modification, are permitted provided that the following conditions > > +* are met: > > +* 1. Redistributions of source code must retain the above copyright > > +*notice, this list of conditions and the following disclaimer. > > +* 2. Redistributions in binary form must reproduce the above copyright > > +*notice, this list of conditions and the following disclaimer in the > > +*documentation and/or other materials provided with the distribution. > > +* > > +* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > > IS" > > +* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > > +* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > > PURPOSE > > +* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > > +* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > > +* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > > +* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > > +* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > > +* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > > +* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > > THE > > +* POSSIBILITY OF SUCH DAMAGE. > > +*/ > > + > > +/* Defining to have access to function prototype in libc/include/pthread.h > > */ > > +#define _GNU_SOURCE > > + > > +#ifdef HAVE_CONFIG_H > > +#include "config.h" > > +#endif > > + > > +#include > > +#include > > + > > +/* > > + * pthread_cond_clockwait() appears in the Issue 8 POSIX Standard > > + */ > > + > > +int pthread_cond_clockwait( > > + pthread_cond_t*restrict cond, > > + pthread_mutex_t *restrict mutex, > > + clockid_t
[PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy
CID 1506207: Buffer not null terminated
Closes #4491
---
tester/covoar/TraceWriterQEMU.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tester/covoar/TraceWriterQEMU.cc b/tester/covoar/TraceWriterQEMU.cc
index c417745..be9b6e1 100644
--- a/tester/covoar/TraceWriterQEMU.cc
+++ b/tester/covoar/TraceWriterQEMU.cc
@@ -106,7 +106,10 @@ namespace Trace {
//
// Write the Header to the file
//
-strncpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
+// The header.magic field is actually 12 bytes, but QEMU_TRACE_MAGIC is
+// 13 bytes including the NULL.
+const char qemu_trace_magic[13] = QEMU_TRACE_MAGIC;
+memcpy( header.magic, qemu_trace_magic, sizeof(header.magic) );
header.version = QEMU_TRACE_VERSION;
header.kind= QEMU_TRACE_KIND_RAW; // XXX ??
header.sizeof_target_pc = 32;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
Hallo Peter,
I do not know if this is best practice but I run the following code:
static void
default_network_dhcpcd(void)
{
static const char default_cfg[] = "clientid test client\n";
rtems_status_code sc;
int fd;
int rv;
ssize_t n;
struct stat statbuf;
if (ENOENT == stat("/etc/dhcpcd.conf", &statbuf)) {
fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
S_IRWXU | S_IRWXG | S_IRWXO);
assert(fd >= 0);
n = write(fd, default_cfg, sizeof(default_cfg) - 1);
assert(n == (ssize_t) sizeof(default_cfg) - 1);
static const char fhi_cfg[] =
"nodhcp6\n"
"ipv4only\n"
"option ntp_servers\n"
"option rtems_cmdline\n"
"option tftp_server_name\n"
"option bootfile_name\n"
"define 129 string rtems_cmdline\n"
"timeout 0";
n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
assert(n == (ssize_t) sizeof(fhi_cfg) - 1);
rv = close(fd);
assert(rv == 0);
}
sc = rtems_dhcpcd_start(NULL);
assert(sc == RTEMS_SUCCESSFUL);
}
Heinz
On 2021-08-19 12:16, Peter Dufault wrote:
I'd like to use the DHCP option 17 (Root Path) to get a mount point
for NFS from the DHCP server.
I'm starting dhcp with "rtems_dhcpcd_start(NULL)" so it's starting
with only the argv array of {"dhcpcd", NULL }.
I *think* I need to start it with a customized rtems_dhcpcd_config
that would maybe include a "--option" argument, and retrieve it in a
run hook (I'm using the run hook already to wait for an IP address to
be assigned). The FreeBSD "--option" documentation is:
-o, --option "option"
Request the DHCP "option" variable for use in
"/usr/local/libexec/dhcpcd-run-hooks".
which would be an argv of {"dhcpcd", "--option", "17", NULL }.
Or is best practice to do something with "rtems-bsd-rc-conf-net.c"?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] aarch64: Add tests that are failing intermittently
- Change status of all spintrcritical tests to indeterminate, expanded upon comments. - Add indeterminate tests to xilinx-versal --- spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++--- spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 ++- spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++--- 3 files changed, 120 insertions(+), 14 deletions(-) diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml b/spec/build/bsps/aarch64/a53/tsta53.yml index f263557..6e8f348 100644 --- a/spec/build/bsps/aarch64/a53/tsta53.yml +++ b/spec/build/bsps/aarch64/a53/tsta53.yml @@ -1,20 +1,26 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: - set-test-state: -# expected to fail, don't compile these +# This test fails when ran through rtems-tester because it does not +# produce any output. minimum: exclude -# don't compile due to toolchain issues +# These tests do not compile due to an issue with the GNU Assembler. +# The issue has been filed(https://devel.rtems.org/ticket/4218). +# Once the issue has been fixed, these tests will be turned back on. spconfig01: exclude spmisc01: exclude -# tests that are passing intermittently +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with QEMU. spcpucounter01: indeterminate +sptimecounter01: indeterminate rtmonuse: indeterminate -sp68: indeterminate sp04: indeterminate sp20: indeterminate +sp68: indeterminate sp69: indeterminate +sp71: indeterminate rtmonusxtimes01: indeterminate spedfsched02: indeterminate spedfsched04: indeterminate @@ -24,12 +30,34 @@ actions: sptimecounter04: indeterminate ttest02: indeterminate -# tests that pass nominally, but fail under Qemu when the host is under -# heavy load +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with Qemu, and that this only occurs when the +# host machine is under a heavy load. psx12: indeterminate +spintrcritical01: indeterminate +spintrcritical02: indeterminate spintrcritical03: indeterminate spintrcritical04: indeterminate spintrcritical05: indeterminate +spintrcritical06: indeterminate +spintrcritical07: indeterminate +spintrcritical08: indeterminate +spintrcritical09: indeterminate +spintrcritical10: indeterminate +spintrcritical11: indeterminate +spintrcritical12: indeterminate +spintrcritical13: indeterminate +spintrcritical14: indeterminate +spintrcritical15: indeterminate +spintrcritical16: indeterminate +spintrcritical17: indeterminate +spintrcritical18: indeterminate +spintrcritical19: indeterminate +spintrcritical20: indeterminate +spintrcritical21: indeterminate +spintrcritical22: indeterminate +spintrcritical23: indeterminate +spintrcritical24: indeterminate build-type: option copyrights: - Copyright (C) 2020 On-Line Applications Research (OAR) diff --git a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml index 43f6b2e..884effc 100644 --- a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml +++ b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml @@ -1,13 +1,63 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: - set-test-state: -# expected to fail +# This test fails when ran through rtems-tester because it does not +# produce any output. minimum: exclude -# don't compile due to toolchain issues, see RTEMS issue #4218 +# These tests do not compile due to an issue with the GNU Assembler. +# The issue has been filed(https://devel.rtems.org/ticket/4218). +# Once the issue has been fixed, these tests will be turned back on. spconfig01: exclude spmisc01: exclude +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with Qemu. +spcpucounter01: indeterminate +sptimecounter01: indeterminate +rtmonuse: indeterminate +sp04: indeterminate +sp20: indeterminate +sp68: indeterminate +sp69: indeterminate +sp71: indeterminate +rtmonusxtimes01: indeterminate +spedfsched02: indeterminate +spedfsched04: indeterminate +psxtimes01: indeterminate +sprmsched01: indeterminate +sptimecounter02: indeterminate +sptimecounter04: indeterminate +ttest02: indeterminate + +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with Qemu, and that this only occurs when the +# host machine is under a heavy load. +psx12: indeterminate +spintrcritical01: indeterminate +spintrcritical02: indeterminate +spintrcritical03: indeterminate +spintrcritical04: indeterminate +spintrcritical05: indeterminate +
[PATCH 0/1] v2: Implement Condclockwait and Test
Dr Joel, Thank you for your feedback! This patch aims to implement your suggested edits. Sincerely, Matt Matt Joyce (1): Added implementation / tests for pthread_cond_clockwait() cpukit/include/rtems/posix/condimpl.h | 7 +- cpukit/posix/src/condclockwait.c | 78 +++ cpukit/posix/src/condtimedwait.c | 3 +- cpukit/posix/src/condwait.c | 6 +- cpukit/posix/src/condwaitsupp.c | 75 ++- spec/build/testsuites/psxtests/grp.yml| 2 + spec/build/testsuites/psxtests/psxcond03.yml | 20 + testsuites/psxtests/Makefile.am | 9 + testsuites/psxtests/configure.ac | 1 + testsuites/psxtests/psxcond03/init.c | 531 ++ testsuites/psxtests/psxcond03/psxcond03.doc | 44 ++ testsuites/psxtests/psxcond03/psxcond03.scn | 67 +++ testsuites/psxtests/psxcond03/system.h| 61 ++ .../psxhdrs/pthread/pthread_cond_clockwait.c | 2 +- 14 files changed, 875 insertions(+), 31 deletions(-) create mode 100644 cpukit/posix/src/condclockwait.c create mode 100644 spec/build/testsuites/psxtests/psxcond03.yml create mode 100644 testsuites/psxtests/psxcond03/init.c create mode 100644 testsuites/psxtests/psxcond03/psxcond03.doc create mode 100644 testsuites/psxtests/psxcond03/psxcond03.scn create mode 100644 testsuites/psxtests/psxcond03/system.h -- 2.31.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/1] v2: Implement Condclockwait and Test
Added implementation of the pthread_cond_clockwait()
method to cpukit/posix/src/condclockwait.c. Additional
logic added to condwaitsupp.c to implement new method.
pthread_cond_clockwait() has been added to the Issue 8
POSIX Standard.
psxcond03 test added to testsuites/psxtests to test the
newly added method.
---
cpukit/include/rtems/posix/condimpl.h | 7 +-
cpukit/posix/src/condclockwait.c | 78 +++
cpukit/posix/src/condtimedwait.c | 3 +-
cpukit/posix/src/condwait.c | 6 +-
cpukit/posix/src/condwaitsupp.c | 75 ++-
spec/build/testsuites/psxtests/grp.yml| 2 +
spec/build/testsuites/psxtests/psxcond03.yml | 20 +
testsuites/psxtests/Makefile.am | 9 +
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxcond03/init.c | 531 ++
testsuites/psxtests/psxcond03/psxcond03.doc | 44 ++
testsuites/psxtests/psxcond03/psxcond03.scn | 67 +++
testsuites/psxtests/psxcond03/system.h| 61 ++
.../psxhdrs/pthread/pthread_cond_clockwait.c | 2 +-
14 files changed, 875 insertions(+), 31 deletions(-)
create mode 100644 cpukit/posix/src/condclockwait.c
create mode 100644 spec/build/testsuites/psxtests/psxcond03.yml
create mode 100644 testsuites/psxtests/psxcond03/init.c
create mode 100644 testsuites/psxtests/psxcond03/psxcond03.doc
create mode 100644 testsuites/psxtests/psxcond03/psxcond03.scn
create mode 100644 testsuites/psxtests/psxcond03/system.h
diff --git a/cpukit/include/rtems/posix/condimpl.h
b/cpukit/include/rtems/posix/condimpl.h
index 66e09bf6d8..95839e17d5 100644
--- a/cpukit/include/rtems/posix/condimpl.h
+++ b/cpukit/include/rtems/posix/condimpl.h
@@ -150,9 +150,10 @@ int _POSIX_Condition_variables_Signal_support(
* timed wait version of condition variable wait routines.
*/
int _POSIX_Condition_variables_Wait_support(
- pthread_cond_t*cond,
- pthread_mutex_t *mutex,
- const struct timespec *abstime
+ pthread_cond_t*restrict cond,
+ pthread_mutex_t *restrict mutex,
+ clockid_t clock_id,
+ const struct timespec *restrict abstime
);
bool _POSIX_Condition_variables_Auto_initialization(
diff --git a/cpukit/posix/src/condclockwait.c b/cpukit/posix/src/condclockwait.c
new file mode 100644
index 00..c2f071a749
--- /dev/null
+++ b/cpukit/posix/src/condclockwait.c
@@ -0,0 +1,78 @@
+/**
+ * @file
+ *
+ * @ingroup POSIXAPI
+ *
+ * @brief Waiting on a Condition
+ */
+
+/*
+* Copyright (C) 2021 Matthew Joyce
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+* 1. Redistributions of source code must retain the above copyright
+*notice, this list of conditions and the following disclaimer.
+* 2. Redistributions in binary form must reproduce the above copyright
+*notice, this list of conditions and the following disclaimer in the
+*documentation and/or other materials provided with the distribution.
+*
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+* POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/* Defining to have access to function prototype in libc/include/pthread.h */
+#define _GNU_SOURCE
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+
+/*
+ * pthread_cond_clockwait() appears in the Issue 8 POSIX Standard
+ */
+int pthread_cond_clockwait(
+ pthread_cond_t *restrict cond,
+ pthread_mutex_t *restrict mutex,
+ clockid_tclock_id,
+ const struct timespec*restrict abstime
+)
+{
+ /*
+ * POSIX Issue 8 does not specify that EINVAL is returned when abstime
+ * equals NULL.
+ */
+ if ( abstime == NULL ) {
+return EINVAL;
+ }
+
+ /*
+ * POSIX Issue 8 specifies that EINVAL is returned when the clock is not
+ * supported.
+ */
+ if ( clock_id != CLOCK_REALTIME ) {
+if ( clock_id != CLOCK_MONOTONIC ) {
+ return EINVAL;
+}
+ }
+
+ return _POSIX_Condition_variables_Wait_support(
+cond,
+mutex,
+clock_id,
+abstime
+ );
+}
diff --git a/cpukit/posix/src/condtimedwait.c b/cpukit/posix/src/condtimedwait.c
index 0b
Re: [PATCH] gdb: prefere python3 if it is installed
I have no problem with this. I think it is sensible to look for
python3 before python2. At some point we'll have to stop looking for
python2 :)
On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
wrote:
>
> PS: I had the problem on the 5 branch of RTEMS source builder. I think
> we should apply a patch to both: master and the 5 branch.
>
> Am 19.08.21 um 10:34 schrieb Christian Mauderer:
> > More and more systems stop shipping python2. So we should start to
> > prefer python3 over python2. For building gdb it is not only necessary
> > to have a python binary installed, but also the matching python-devel
> > packet. On a lot of hosts that will now be more often python3-devel
> > and not python2-devel.
> > ---
> >
> > Note: Please see that patch more as an suggestion / base for
> > discussion. I'm open to better solutions.
> >
> > My problem that triggered this patch was a build of a toolchain on a
> > github CI/CD system that has been originally set up by one of our
> > users (see [1] for the log). It seems that on the "macos-latest"
> > machines a python2 is installed but no python2 headers are found.
> > Homebrew - which could be used earlier on MacOS to install the
> > necessary headers - dropped the python@2 packet. So it seems that on a
> > modern MacOS there is no possibility to get python2 headers. If
> > python2 is still installed on the machine (for whatever reason), it is
> > not possible to successfully use RTEMS source builder to build a gdb.
> > If python3 is preferred instead, that should solve the problem.
> >
> > Note that at the moment I only tried it on my OpenSUSE-Linux machine.
> > For that I made sure that I have python2 and python3 installed but no
> > python-devel (which is python2 on OpenSUSE). Earlier I know that I
> > needed python-devel to build gdb. With this patch, I can build with
> > only python3-devel.
> >
> > I'll try to add that patch to the CI too to see whether it works on
> > MacOS. But I'm a bit unsure what other problems this patch could
> > trigger and therefore I want to start a discussion early.
> >
> > Best regards
> >
> > Christian
> >
> > [1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
> > Note: The "Get Errorinfo" step prints the rsb-report-*.txt
> >
> >
> > source-builder/config/gdb-common-1.cfg | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/source-builder/config/gdb-common-1.cfg
> > b/source-builder/config/gdb-common-1.cfg
> > index 397d44d..42fe263 100644
> > --- a/source-builder/config/gdb-common-1.cfg
> > +++ b/source-builder/config/gdb-common-1.cfg
> > @@ -42,7 +42,7 @@
> > # 2. Does the version of gdb specify a version of python that must be
> > #used. Override with '%define gdb-python-version python2'.
> > #
> > -# 3. Search for 'python2' and if not found search for 'python3'.
> > +# 3. Search for 'python3' and if not found search for 'python2'.
> > #
> > %if %{defined gdb-python2}
> > %define gdb-enable-python %{gdb_python2}
> > @@ -53,9 +53,9 @@
> > %if %{defined gdb-python-version}
> > %define gdb-enable-python %(command -v %{gdb-python-version} ||
> > true)
> > %else
> > - %define gdb-enable-python %(command -v python2 || true)
> > + %define gdb-enable-python %(command -v python3 || true)
> > %if %{gdb-enable-python} == %{nil}
> > -%define gdb-enable-python %(command -v python3 || true)
> > +%define gdb-enable-python %(command -v python2 || true)
> > %endif
> > %if %{gdb-enable-python} == %{nil}
> > %define gdb-enable-python %(command -v python || true})
> >
>
> --
>
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] aarch64: Add tests that are failing intermittently
Can you explain the process for generating the lists of indeterminate test results? I hate to circle this subject so many times, but is labeling sporadic simulator failures as indeterminate results really the right thing to do? Are these indeterminate tests reproducible on different systems/qemus/loads? Or is it just what you observe locally when running rtems-test on one specific system? I don't think I see nearly so many spurious failures when I run rtems-test for example. I really need to believe we're not just hiding a system configuration problem. I know I OK'd looking at the versal, but on second thought, I'd rather leave the xilinx-versal/tstqemu.yml alone until the BSP is finished, so revert that part of your patch. Sorry about that. Gedare On Thu, Aug 19, 2021 at 9:53 AM Ryan Long wrote: > > - Change status of all spintrcritical tests to indeterminate, expanded upon > comments. > - Add indeterminate tests to xilinx-versal > --- > spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++--- > spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 > ++- > spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++--- > 3 files changed, 120 insertions(+), 14 deletions(-) > > diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml > b/spec/build/bsps/aarch64/a53/tsta53.yml > index f263557..6e8f348 100644 > --- a/spec/build/bsps/aarch64/a53/tsta53.yml > +++ b/spec/build/bsps/aarch64/a53/tsta53.yml > @@ -1,20 +1,26 @@ > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > actions: > - set-test-state: > -# expected to fail, don't compile these > +# This test fails when ran through rtems-tester because it does not > +# produce any output. > minimum: exclude > > -# don't compile due to toolchain issues > +# These tests do not compile due to an issue with the GNU Assembler. > +# The issue has been filed(https://devel.rtems.org/ticket/4218). > +# Once the issue has been fixed, these tests will be turned back on. > spconfig01: exclude > spmisc01: exclude > > -# tests that are passing intermittently > +# These tests may or may not fail, however, they do pass on real > hardware. > +# It seems to be an issue with QEMU. > spcpucounter01: indeterminate > +sptimecounter01: indeterminate > rtmonuse: indeterminate > -sp68: indeterminate > sp04: indeterminate > sp20: indeterminate > +sp68: indeterminate > sp69: indeterminate > +sp71: indeterminate > rtmonusxtimes01: indeterminate > spedfsched02: indeterminate > spedfsched04: indeterminate > @@ -24,12 +30,34 @@ actions: > sptimecounter04: indeterminate > ttest02: indeterminate > > -# tests that pass nominally, but fail under Qemu when the host is under > -# heavy load > +# These tests may or may not fail, however, they do pass on real > hardware. > +# It seems to be an issue with Qemu, and that this only occurs when the > +# host machine is under a heavy load. > psx12: indeterminate > +spintrcritical01: indeterminate > +spintrcritical02: indeterminate > spintrcritical03: indeterminate > spintrcritical04: indeterminate > spintrcritical05: indeterminate > +spintrcritical06: indeterminate > +spintrcritical07: indeterminate > +spintrcritical08: indeterminate > +spintrcritical09: indeterminate > +spintrcritical10: indeterminate > +spintrcritical11: indeterminate > +spintrcritical12: indeterminate > +spintrcritical13: indeterminate > +spintrcritical14: indeterminate > +spintrcritical15: indeterminate > +spintrcritical16: indeterminate > +spintrcritical17: indeterminate > +spintrcritical18: indeterminate > +spintrcritical19: indeterminate > +spintrcritical20: indeterminate > +spintrcritical21: indeterminate > +spintrcritical22: indeterminate > +spintrcritical23: indeterminate > +spintrcritical24: indeterminate > build-type: option > copyrights: > - Copyright (C) 2020 On-Line Applications Research (OAR) > diff --git a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml > b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml > index 43f6b2e..884effc 100644 > --- a/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml > +++ b/spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml > @@ -1,13 +1,63 @@ > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > actions: > - set-test-state: > -# expected to fail > +# This test fails when ran through rtems-tester because it does not > +# produce any output. > minimum: exclude > > -# don't compile due to toolchain issues, see RTEMS issue #4218 > +# These tests do not compile due to an issue with the GNU Assembler. > +# The issue has been filed(https://devel.rtems.org/ticket/4218). > +# Once the issue has been fixed, these tests will be turned back on. > spconfig01: exclude > spmisc01: exclude > > +
Re: [PATCH] gdb: prefere python3 if it is installed
On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote:
>
> I have no problem with this. I think it is sensible to look for
> python3 before python2. At some point we'll have to stop looking for
> python2 :)
That is further in the future than I would have thought based on the
CentOS project changes. I still see user organizations with no plans
to move off CentOS 7. It will receive maintenance updates through
2024-06-30.
But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't
that bad. I had to test something on a true 32-bit distribution this week
and even CentOS 7 (i386) wasn't as painful as I expected to setup.
--joel
> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
> wrote:
> >
> > PS: I had the problem on the 5 branch of RTEMS source builder. I think
> > we should apply a patch to both: master and the 5 branch.
> >
> > Am 19.08.21 um 10:34 schrieb Christian Mauderer:
> > > More and more systems stop shipping python2. So we should start to
> > > prefer python3 over python2. For building gdb it is not only necessary
> > > to have a python binary installed, but also the matching python-devel
> > > packet. On a lot of hosts that will now be more often python3-devel
> > > and not python2-devel.
> > > ---
> > >
> > > Note: Please see that patch more as an suggestion / base for
> > > discussion. I'm open to better solutions.
> > >
> > > My problem that triggered this patch was a build of a toolchain on a
> > > github CI/CD system that has been originally set up by one of our
> > > users (see [1] for the log). It seems that on the "macos-latest"
> > > machines a python2 is installed but no python2 headers are found.
> > > Homebrew - which could be used earlier on MacOS to install the
> > > necessary headers - dropped the python@2 packet. So it seems that on a
> > > modern MacOS there is no possibility to get python2 headers. If
> > > python2 is still installed on the machine (for whatever reason), it is
> > > not possible to successfully use RTEMS source builder to build a gdb.
> > > If python3 is preferred instead, that should solve the problem.
> > >
> > > Note that at the moment I only tried it on my OpenSUSE-Linux machine.
> > > For that I made sure that I have python2 and python3 installed but no
> > > python-devel (which is python2 on OpenSUSE). Earlier I know that I
> > > needed python-devel to build gdb. With this patch, I can build with
> > > only python3-devel.
> > >
> > > I'll try to add that patch to the CI too to see whether it works on
> > > MacOS. But I'm a bit unsure what other problems this patch could
> > > trigger and therefore I want to start a discussion early.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> > > [1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
> > > Note: The "Get Errorinfo" step prints the rsb-report-*.txt
> > >
> > >
> > > source-builder/config/gdb-common-1.cfg | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/source-builder/config/gdb-common-1.cfg
> > > b/source-builder/config/gdb-common-1.cfg
> > > index 397d44d..42fe263 100644
> > > --- a/source-builder/config/gdb-common-1.cfg
> > > +++ b/source-builder/config/gdb-common-1.cfg
> > > @@ -42,7 +42,7 @@
> > > # 2. Does the version of gdb specify a version of python that must be
> > > #used. Override with '%define gdb-python-version python2'.
> > > #
> > > -# 3. Search for 'python2' and if not found search for 'python3'.
> > > +# 3. Search for 'python3' and if not found search for 'python2'.
> > > #
> > > %if %{defined gdb-python2}
> > > %define gdb-enable-python %{gdb_python2}
> > > @@ -53,9 +53,9 @@
> > > %if %{defined gdb-python-version}
> > > %define gdb-enable-python %(command -v %{gdb-python-version} ||
> > > true)
> > > %else
> > > - %define gdb-enable-python %(command -v python2 || true)
> > > + %define gdb-enable-python %(command -v python3 || true)
> > > %if %{gdb-enable-python} == %{nil}
> > > -%define gdb-enable-python %(command -v python3 || true)
> > > +%define gdb-enable-python %(command -v python2 || true)
> > > %endif
> > > %if %{gdb-enable-python} == %{nil}
> > > %define gdb-enable-python %(command -v python || true})
> > >
> >
> > --
> >
> > embedded brains GmbH
> > Herr Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: christian.maude...@embedded-brains.de
> > phone: +49-89-18 94 741 - 18
> > fax: +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
Re: [PATCH] aarch64: Add tests that are failing intermittently
I've seen these failures on my local system, in our CI, and on a build server that I sometimes use for development/testing so if it's a configuration issue we're being pretty consistent about misconfiguration across some pretty different environments (docker, bare-metal, VM, different OSs, different QEMU versions). I've seen enough of the spintrcritical tests fail sporadically on QEMU to lump them all into this category. These are also tests that I have seen behave badly on ARMv7 QEMU on my local system (which doesn't rule out misconfiguration, but it's another data point). As far as your worry about marking these indeterminate, they're only being marked as such for QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs and runs all these tests flawlessly. These failures become much more common when there is otherwise load on the system and a lot of them disappear when you limit the tester to a single QEMU instance at a time. Kinsey On 8/19/2021 11:58, Gedare Bloom wrote: Can you explain the process for generating the lists of indeterminate test results? I hate to circle this subject so many times, but is labeling sporadic simulator failures as indeterminate results really the right thing to do? Are these indeterminate tests reproducible on different systems/qemus/loads? Or is it just what you observe locally when running rtems-test on one specific system? I don't think I see nearly so many spurious failures when I run rtems-test for example. I really need to believe we're not just hiding a system configuration problem. I know I OK'd looking at the versal, but on second thought, I'd rather leave the xilinx-versal/tstqemu.yml alone until the BSP is finished, so revert that part of your patch. Sorry about that. Gedare On Thu, Aug 19, 2021 at 9:53 AM Ryan Long wrote: - Change status of all spintrcritical tests to indeterminate, expanded upon comments. - Add indeterminate tests to xilinx-versal --- spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++--- spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 ++- spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++--- 3 files changed, 120 insertions(+), 14 deletions(-) diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml b/spec/build/bsps/aarch64/a53/tsta53.yml index f263557..6e8f348 100644 --- a/spec/build/bsps/aarch64/a53/tsta53.yml +++ b/spec/build/bsps/aarch64/a53/tsta53.yml @@ -1,20 +1,26 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: - set-test-state: -# expected to fail, don't compile these +# This test fails when ran through rtems-tester because it does not +# produce any output. minimum: exclude -# don't compile due to toolchain issues +# These tests do not compile due to an issue with the GNU Assembler. +# The issue has been filed(https://devel.rtems.org/ticket/4218). +# Once the issue has been fixed, these tests will be turned back on. spconfig01: exclude spmisc01: exclude -# tests that are passing intermittently +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with QEMU. spcpucounter01: indeterminate +sptimecounter01: indeterminate rtmonuse: indeterminate -sp68: indeterminate sp04: indeterminate sp20: indeterminate +sp68: indeterminate sp69: indeterminate +sp71: indeterminate rtmonusxtimes01: indeterminate spedfsched02: indeterminate spedfsched04: indeterminate @@ -24,12 +30,34 @@ actions: sptimecounter04: indeterminate ttest02: indeterminate -# tests that pass nominally, but fail under Qemu when the host is under -# heavy load +# These tests may or may not fail, however, they do pass on real hardware. +# It seems to be an issue with Qemu, and that this only occurs when the +# host machine is under a heavy load. psx12: indeterminate +spintrcritical01: indeterminate +spintrcritical02: indeterminate spintrcritical03: indeterminate spintrcritical04: indeterminate spintrcritical05: indeterminate +spintrcritical06: indeterminate +spintrcritical07: indeterminate +spintrcritical08: indeterminate +spintrcritical09: indeterminate +spintrcritical10: indeterminate +spintrcritical11: indeterminate +spintrcritical12: indeterminate +spintrcritical13: indeterminate +spintrcritical14: indeterminate +spintrcritical15: indeterminate +spintrcritical16: indeterminate +spintrcritical17: indeterminate +spintrcritical18: indeterminate +spintrcritical19: indeterminate +spintrcritical20: indeterminate +spintrcritical21: indeterminate +spintrcritical22: indeterminate +spintrcritical23: indeterminate +spintrcritical24: indeterminate build-type: option copyrights: - Copyright (C) 2020 On-Line Applications Research (OAR) diff -
Re: [PATCH] aarch64: Add tests that are failing intermittently
On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote: > > I've seen these failures on my local system, in our CI, and on a build > server that I sometimes > use for development/testing so if it's a configuration issue we're being > pretty consistent about > misconfiguration across some pretty different environments (docker, > bare-metal, VM, different > OSs, different QEMU versions). I've seen enough of the spintrcritical > tests fail sporadically on > QEMU to lump them all into this category. These are also tests that I > have seen behave badly > on ARMv7 QEMU on my local system (which doesn't rule out > misconfiguration, but it's another > data point). > Yes, for example, it may be a matter of qemu process counts spawned by rtems-test, and the order in which tests get invoked could be a cause for which ones don't work. I could easily see this happening, since each test runtime will be fairly consistent, so you'll often see the same tests running concurrently with each other. But, if you change the order (e.g., by adding new tests), then we may see a new set of sporadically failing testcases, will we just add those, or do we need to re-examine this indetermine set periodically? Who will maintain this list? That's kind of the root of my concern here. > As far as your worry about marking these indeterminate, they're only > being marked as such for > QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs > and runs all > these tests flawlessly. > > These failures become much more common when there is otherwise load on > the system and a > lot of them disappear when you limit the tester to a single QEMU > instance at a time. > I'm wondering if we should sacrifice testing speed for coverage/quality. If throttling rtems-test leads to more reliable test results, then it may be a better option than basically ignoring a swath of our testsuite. > > Kinsey > > > On 8/19/2021 11:58, Gedare Bloom wrote: > > Can you explain the process for generating the lists of indeterminate > > test results? > > > > I hate to circle this subject so many times, but is labeling sporadic > > simulator failures as indeterminate results really the right thing to > > do? Are these indeterminate tests reproducible on different > > systems/qemus/loads? Or is it just what you observe locally when > > running rtems-test on one specific system? I don't think I see nearly > > so many spurious failures when I run rtems-test for example. I really > > need to believe we're not just hiding a system configuration problem. > > > > I know I OK'd looking at the versal, but on second thought, I'd rather > > leave the xilinx-versal/tstqemu.yml alone until the BSP is finished, > > so revert that part of your patch. Sorry about that. > > > > Gedare > > > > On Thu, Aug 19, 2021 at 9:53 AM Ryan Long wrote: > >> - Change status of all spintrcritical tests to indeterminate, expanded upon > >>comments. > >> - Add indeterminate tests to xilinx-versal > >> --- > >> spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++--- > >> spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 > >> ++- > >> spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++--- > >> 3 files changed, 120 insertions(+), 14 deletions(-) > >> > >> diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml > >> b/spec/build/bsps/aarch64/a53/tsta53.yml > >> index f263557..6e8f348 100644 > >> --- a/spec/build/bsps/aarch64/a53/tsta53.yml > >> +++ b/spec/build/bsps/aarch64/a53/tsta53.yml > >> @@ -1,20 +1,26 @@ > >> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > >> actions: > >> - set-test-state: > >> -# expected to fail, don't compile these > >> +# This test fails when ran through rtems-tester because it does not > >> +# produce any output. > >> minimum: exclude > >> > >> -# don't compile due to toolchain issues > >> +# These tests do not compile due to an issue with the GNU Assembler. > >> +# The issue has been filed(https://devel.rtems.org/ticket/4218). > >> +# Once the issue has been fixed, these tests will be turned back on. > >> spconfig01: exclude > >> spmisc01: exclude > >> > >> -# tests that are passing intermittently > >> +# These tests may or may not fail, however, they do pass on real > >> hardware. > >> +# It seems to be an issue with QEMU. > >> spcpucounter01: indeterminate > >> +sptimecounter01: indeterminate > >> rtmonuse: indeterminate > >> -sp68: indeterminate > >> sp04: indeterminate > >> sp20: indeterminate > >> +sp68: indeterminate > >> sp69: indeterminate > >> +sp71: indeterminate > >> rtmonusxtimes01: indeterminate > >> spedfsched02: indeterminate > >> spedfsched04: indeterminate > >> @@ -24,12 +30,34 @@ actions: > >> sptimecounter04: indeterminate > >> ttest02: indeterminate > >> > >> -# tests that pass nominally, but fail under Qemu when the host
Re: [PATCH] aarch64: Add tests that are failing intermittently
On 8/19/2021 13:32, Gedare Bloom wrote: On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote: I've seen these failures on my local system, in our CI, and on a build server that I sometimes use for development/testing so if it's a configuration issue we're being pretty consistent about misconfiguration across some pretty different environments (docker, bare-metal, VM, different OSs, different QEMU versions). I've seen enough of the spintrcritical tests fail sporadically on QEMU to lump them all into this category. These are also tests that I have seen behave badly on ARMv7 QEMU on my local system (which doesn't rule out misconfiguration, but it's another data point). Yes, for example, it may be a matter of qemu process counts spawned by rtems-test, and the order in which tests get invoked could be a cause for which ones don't work. I could easily see this happening, since each test runtime will be fairly consistent, so you'll often see the same tests running concurrently with each other. But, if you change the order (e.g., by adding new tests), then we may see a new set of sporadically failing testcases, will we just add those, or do we need to re-examine this indetermine set periodically? Who will maintain this list? That's kind of the root of my concern here. I understand your concern about maintenance of the failure list and I don't have a good answer for you. I imagine going forward it would be a combination of the current stake-holders for a given BSP and anyone who watches the automated build output from Joel's runs for these kinds of issues. On the other hand if we don't mark those tests, people will get fatigued looking at the spurious failures and assume any new ones just fall into the same category as others. At that point is it even worth running the automated tests for that platform? As far as your worry about marking these indeterminate, they're only being marked as such for QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs and runs all these tests flawlessly. These failures become much more common when there is otherwise load on the system and a lot of them disappear when you limit the tester to a single QEMU instance at a time. I'm wondering if we should sacrifice testing speed for coverage/quality. If throttling rtems-test leads to more reliable test results, then it may be a better option than basically ignoring a swath of our testsuite. That would certainly mitigate some of the failures, but you'd also have to guarantee nothing else is running on the system which could cause the same problem. I know at least some of the current automated runs operate on a shared system which can and does often have other intensive processes running on it. There are also the tests that are sporadic on QEMU even without additional load. Kinsey On 8/19/2021 11:58, Gedare Bloom wrote: Can you explain the process for generating the lists of indeterminate test results? I hate to circle this subject so many times, but is labeling sporadic simulator failures as indeterminate results really the right thing to do? Are these indeterminate tests reproducible on different systems/qemus/loads? Or is it just what you observe locally when running rtems-test on one specific system? I don't think I see nearly so many spurious failures when I run rtems-test for example. I really need to believe we're not just hiding a system configuration problem. I know I OK'd looking at the versal, but on second thought, I'd rather leave the xilinx-versal/tstqemu.yml alone until the BSP is finished, so revert that part of your patch. Sorry about that. Gedare On Thu, Aug 19, 2021 at 9:53 AM Ryan Long wrote: - Change status of all spintrcritical tests to indeterminate, expanded upon comments. - Add indeterminate tests to xilinx-versal --- spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++--- spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 ++- spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++--- 3 files changed, 120 insertions(+), 14 deletions(-) diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml b/spec/build/bsps/aarch64/a53/tsta53.yml index f263557..6e8f348 100644 --- a/spec/build/bsps/aarch64/a53/tsta53.yml +++ b/spec/build/bsps/aarch64/a53/tsta53.yml @@ -1,20 +1,26 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: - set-test-state: -# expected to fail, don't compile these +# This test fails when ran through rtems-tester because it does not +# produce any output. minimum: exclude -# don't compile due to toolchain issues +# These tests do not compile due to an issue with the GNU Assembler. +# The issue has been filed(https://devel.rtems.org/ticket/4218). +# Once the issue has been fixed, these tests will be turned back on. spconfig01: exclude spmisc01: exclude -# tests that are passing intermittently +# These tests may o
Re: [PATCH rtems] arm/xilinx: Fix zynq-uart interrupt receive
On 19/8/21 10:45 pm, Kinsey Moore wrote: > On 8/18/2021 18:02, Chris Johns wrote: >> On 19/8/21 5:49 am, Kinsey Moore wrote: >>> On 8/18/2021 13:20, Chris Johns wrote: On 19/8/21 3:41 am, Kinsey Moore wrote: > This is functional on the ZynqMP board I currently have setup for testing > and on > ZynqMP QEMU except for the data corruption/loss caused by the removal of > the > post-baud-set null write. Thanks for the testing. I am not sure if you are saying both the ZyncMP hardware and qemu need the write or just qemu. The write may work but it does not make sense because at some point the software will print a character and achive the same thing? >>> QEMU works fine either way. The ZynqMP hardware is what has issues without >>> the >>> null write. >> OK >> >>> The problem is that it's picky about which characters will actually fix the >>> data >>> loss/corruption. >>> I've seen that both space and null will do it while letters and numbers >>> won't. >>> Null was chosen specifically because it's not printable. >> It shows up on Zynq consoles I have running a a junk character. >> >>> Without this null print, I see garbage >>> output and it eventually starts printing text correctly. >> How many characters? It smells like a clock is hunting. I suggest you ask >> Joel >> to raise this with Xilinx to see if there is any known errata. > The number varies depending on the text being output. It continues spewing bad > characters until > it encounters a character that resets whatever internal mechanism is causing > this. I'll see if we can get some information from Xilinx. Interesting. A nul character means a single level on the line and that implies a signal filtering issue, ie a low freq signal. >> Another suggestion is downloading the Xilinx SDK and looking over the bare >> metal >> console support to see what they do there. > The sticking point here seems to be baud rate manipulation and the TX/RX reset > that must occur. > The bare metal driver has code for this, but it is never called as far as I > can > tell. I still haven't found > the startup sequence that initializes the UART, but I'll take another look. Ok and thanks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] aarch64: Add tests that are failing intermittently
On 20/8/21 2:58 am, Gedare Bloom wrote: > I know I OK'd looking at the versal, but on second thought, I'd rather > leave the xilinx-versal/tstqemu.yml alone until the BSP is finished, > so revert that part of your patch. Sorry about that. Agreed, please leave the Versal as is. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] aarch64: Add tests that are failing intermittently
On 20/8/21 4:55 am, Kinsey Moore wrote: > On 8/19/2021 13:32, Gedare Bloom wrote: >> On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore >> wrote: >>> I've seen these failures on my local system, in our CI, and on a build >>> server that I sometimes >>> use for development/testing so if it's a configuration issue we're being >>> pretty consistent about >>> misconfiguration across some pretty different environments (docker, >>> bare-metal, VM, different >>> OSs, different QEMU versions). I've seen enough of the spintrcritical >>> tests fail sporadically on >>> QEMU to lump them all into this category. These are also tests that I >>> have seen behave badly >>> on ARMv7 QEMU on my local system (which doesn't rule out >>> misconfiguration, but it's another >>> data point). >>> >> Yes, for example, it may be a matter of qemu process counts spawned by >> rtems-test, and the order in which tests get invoked could be a cause >> for which ones don't work. I could easily see this happening, since >> each test runtime will be fairly consistent, so you'll often see the >> same tests running concurrently with each other. But, if you change >> the order (e.g., by adding new tests), then we may see a new set of >> sporadically failing testcases, will we just add those, or do we need >> to re-examine this indetermine set periodically? Who will maintain >> this list? That's kind of the root of my concern here. > I understand your concern about maintenance of the failure list and I don't > have a good answer for you. I imagine going forward it would be a combination > of the current stake-holders for a given BSP and anyone who watches the > automated build output from Joel's runs for these kinds of issues. > > On the other hand if we don't mark those tests, people will get fatigued > looking at the spurious failures and assume any new ones just fall into the > same category as others. At that point is it even worth running the > automated tests for that platform? > >> >>> As far as your worry about marking these indeterminate, they're only >>> being marked as such for >>> QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs >>> and runs all these tests flawlessly. Great, this is important. >>> These failures become much more common when there is otherwise load on >>> the system and a >>> lot of them disappear when you limit the tester to a single QEMU >>> instance at a time. >>> >> I'm wondering if we should sacrifice testing speed for >> coverage/quality. If throttling rtems-test leads to more reliable test >> results, then it may be a better option than basically ignoring a >> swath of our testsuite. > That would certainly mitigate some of the failures, but you'd also have to > guarantee nothing else is running on the system which could cause the same > problem. I know at least some of the current automated runs operate on a > shared system which can and does often have other intensive processes > running on it. There are also the tests that are sporadic on QEMU even > without additional load. What is it in these tests when combined with qemu that causes the tests to fail? Is there some relation to a real clock, some shared host resource or a bug in qemu? I am concerned a simulator can vary like this based on the host's load and it makes me wonder how people use it on machines to host a number VMs. I feel with this volume of tests being tagged this way we should have a better understanding of the problem and so a means to track or not track how to resolve it. As Gedare has kindly stated once pushed this change disappears into a dark corner and we have no means to track it. The other solution is to set `jobs` to `1` in this BSP's tester config, again something Gedare has raised. It means we get better or even valid results. What is more important, valid results or running the testsuite as fast as possible? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using libbsd dhcpcd options
On 20/8/21 1:45 am, junkes wrote:
> Hallo Peter,
> I do not know if this is best practice but I run the following code:
>
> static void
> default_network_dhcpcd(void)
> {
> static const char default_cfg[] = "clientid test client\n";
> rtems_status_code sc;
> int fd;
> int rv;
> ssize_t n;
> struct stat statbuf;
>
> if (ENOENT == stat("/etc/dhcpcd.conf", &statbuf)) {
> fd = open("/etc/dhcpcd.conf", O_CREAT | O_WRONLY,
> S_IRWXU | S_IRWXG | S_IRWXO);
> assert(fd >= 0);
>
> n = write(fd, default_cfg, sizeof(default_cfg) - 1);
> assert(n == (ssize_t) sizeof(default_cfg) - 1);
>
> static const char fhi_cfg[] =
> "nodhcp6\n"
> "ipv4only\n"
> "option ntp_servers\n"
> "option rtems_cmdline\n"
> "option tftp_server_name\n"
> "option bootfile_name\n"
> "define 129 string rtems_cmdline\n"
> "timeout 0";
>
> n = write(fd, fhi_cfg, sizeof(fhi_cfg) - 1);
> assert(n == (ssize_t) sizeof(fhi_cfg) - 1);
>
> rv = close(fd);
> assert(rv == 0);
> }
>
> sc = rtems_dhcpcd_start(NULL);
> assert(sc == RTEMS_SUCCESSFUL);
> }
Hienz, this is a good solution and using a file best solution.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
On 20/8/21 3:16 am, Joel Sherrill wrote: > On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: >> >> I have no problem with this. I think it is sensible to look for >> python3 before python2. At some point we'll have to stop looking for >> python2 :) > > That is further in the future than I would have thought based on the > CentOS project changes. I still see user organizations with no plans > to move off CentOS 7. It will receive maintenance updates through > 2024-06-30. > > But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't > that bad. I had to test something on a true 32-bit distribution this week > and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. >> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER >> wrote: >>> >>> PS: I had the problem on the 5 branch of RTEMS source builder. I think >>> we should apply a patch to both: master and the 5 branch. >>> >>> Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. Homebrew - which could be used earlier on MacOS to install the necessary headers - dropped the python@2 packet. Homebrew and MacPorts are a personal choice and I am fine with users heading down this path however it is beyond this project's scope to support those frameworks. I have posted the reasons in the past and the MacPorts maintainers are aware of those reasons. So it seems that on a modern MacOS there is no possibility to get python2 headers. As I have just built GDB this does not appear to be true. I would prefer we do not overreach until we all agree there is a problem. If there is an issue I would raise the problem in Apple'd developer bug system. I have raised a number of issues over the years and to Apple's credit they have dealt with them all. If python2 is still installed on the machine (for whatever reason), it is not possible to successfully use RTEMS source builder to build a gdb. If python3 is preferred instead, that should solve the problem. The change seems sensible. Note that at the moment I only tried it on my OpenSUSE-Linux machine. For that I made sure that I have python2 and python3 installed but no python-devel (which is python2 on OpenSUSE). Earlier I know that I needed python-devel to build gdb. With this patch, I can build with only python3-devel. I'll try to add that patch to the CI too to see whether it works on MacOS. But I'm a bit unsure what other problems this patch could trigger and therefore I want to start a discussion early. Best regards Christian [1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606 I am looking forward to their hardware being shipped. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v4 0/2] Add MicroBlaze tools to RSB
Hi Alex, These patches are OK to push. One minor point, the script sha512-base64 in the RSB creates a base64 encoded hash and that makes them smaller. I prefer we move to this more and more. Chris On 19/8/21 1:34 pm, Alex White wrote: > Hi, > > This patch set now depends on Joel's newlib hash bump and should be merged > after > it. > > v4: > - Rename to rtems-xilinx-gcc-10-newlib-head.cfg > - Simplify rtems-xilinx-gcc-10-newlib-head.cfg with include > > v3: > - Follow naming convention for Xilinx .cfg files > - Simplify rtems-xilinx-binutils-2.36.cfg with rtems-binutils-2.36.cfg > include > > v2: > - Add Xilinx QEMU version to .cfg filename > - Exclude GDB configuration with unneeded Xilinx patches > > This patch set adds the MicroBlaze tools to rtems-source-builder. > > Thanks, > > Alex > > Alex White (2): > rsb: Add MicroBlaze tools > rsb: Add Xilinx QEMU > > bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 23 ++ > bare/config/devel/qemu-xilinx.bset| 24 ++ > rtems/config/6/rtems-microblaze.bset | 23 +- > .../tools/rtems-xilinx-binutils-2.36.cfg | 40 > .../tools/rtems-xilinx-gcc-10-newlib-head.cfg | 46 +++ > 5 files changed, 155 insertions(+), 1 deletion(-) > create mode 100644 bare/config/devel/qemu-xilinx-v2020.2-1.cfg > create mode 100644 bare/config/devel/qemu-xilinx.bset > create mode 100644 rtems/config/tools/rtems-xilinx-binutils-2.36.cfg > create mode 100644 rtems/config/tools/rtems-xilinx-gcc-10-newlib-head.cfg > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] gdb: prefere python3 if it is installed
Hello, Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21 3:16 am, Joel Sherrill wrote: On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom wrote: I have no problem with this. I think it is sensible to look for python3 before python2. At some point we'll have to stop looking for python2 :) That is further in the future than I would have thought based on the CentOS project changes. I still see user organizations with no plans to move off CentOS 7. It will receive maintenance updates through 2024-06-30. But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't that bad. I had to test something on a true 32-bit distribution this week and even CentOS 7 (i386) wasn't as painful as I expected to setup. There will come a time when a change made cannot be easily tested by us on python2 and that will in effect end our support. We are not there yet. STOP. That discussion took a wrong direction. We discussed deprecating python2 a few times and I know that we will not do it before the big long living distributions drop it. I can live with that and I don't want to re-start this discussion with this patch. On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER wrote: PS: I had the problem on the 5 branch of RTEMS source builder. I think we should apply a patch to both: master and the 5 branch. Am 19.08.21 um 10:34 schrieb Christian Mauderer: More and more systems stop shipping python2. So we should start to prefer python3 over python2. For building gdb it is not only necessary to have a python binary installed, but also the matching python-devel packet. On a lot of hosts that will now be more often python3-devel and not python2-devel. --- Note: Please see that patch more as an suggestion / base for discussion. I'm open to better solutions. My problem that triggered this patch was a build of a toolchain on a github CI/CD system that has been originally set up by one of our users (see [1] for the log). It seems that on the "macos-latest" machines a python2 is installed but no python2 headers are found. I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur): config: tools/rtems-gdb-10.cfg package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB (installed: 19.586MB) cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1 reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt reporting: tools/rtems-gdb-10.cfg -> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml I support the latest MacOS with Xcode and have a dedicated Mac machine that tracks the current RSB. It had wedged itself and I have cleared that so it is now building the latest. So do I understand that correct: This is a "clean" Mac with no additional python installs or similar and it worked? What python versions are available on this this machine? If I did understand you correctly, it seems that github has made some odd choices about their default config for the macos-latest machines. They seem to have python2 but no devel headers. Homebrew - which could be used earlier on MacOS to install the necessary headers - dropped the python@2 packet. Homebrew and MacPorts are a personal choice and I am fine with users heading down this path however it is beyond this project's scope to support those frameworks. I have posted the reasons in the past and the MacPorts maintainers are aware of those reasons. No problem. I'm not a Mac user so I don't really have an opinion or experience what is the right way to install the requirements on a MacOS system. I'm really happy that it just works most of the time (a lot of it most likely thanks to you). So it seems that on a modern MacOS there is no possibility to get python2 headers. As I have just built GDB this does not appear to be true. I would prefer we do not overreach until we all agree there is a problem. If there is an issue I would raise the problem in Apple'd developer bug system. I have raised a number of issues over the years and to Apple's credit they have dealt with them all. Maybe I haven't made it enough clear: I had to do some guess work here. I have put it here as a basis for discussion. I'm completely OK if you can tell me that my conclusion has been wrong. It seems that it really is just an odd choice of defaults on github then. If python2 is still installed on the machine (for whatever reason), it is not possible to successfully use RTEMS source builder to build a gdb. If python3 is preferred instead, that should solve the problem. The change seems sensible. I think even if a clean MacOS doesn't have a problem (like I assumed), I still think it would be a good idea to prefer python3 if it is available. We are not talking about preferring it in our python-scripts but only to build gdb. Do I have a "go" to: - create tickets for 5 and
