[PATCH rtems-source-builder] 6/7: Update AArch64 newlib patch
The existing patch fails to build with the latest newlib. This picks up
an updated patch that compiles with both older and newer newlib.
---
rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index cb26aa0..22a88ba 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -13,8 +13,8 @@
%patch add gcc -p1
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
%hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
-%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly.patch
-%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly.patch
BHRMimj6ztKPHQFxypI8RwPmno96B56eVQGx5dtCtcOb+qICMrQC1fa0jP3JrR8RGJI4y61RoYvpnj6EbTmRKA==
+%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
+%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
%define newlib_version 332df71
%define newlib_external 1
diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
index 6aaad8d..b2bc78f 100644
--- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
@@ -13,8 +13,8 @@
%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
%hash sha512 newlib-%{newlib_version}.tar.gz
ec6db480d5e21f8de520a3c33a22dc08a2be56a6fb817d31d5f16c2f564df4907c1e3f3e7c1cf2368eed1d93b3811cabc1cdffb922d3df05ba7fe960eabd265b
-%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly.patch
-%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly.patch
BHRMimj6ztKPHQFxypI8RwPmno96B56eVQGx5dtCtcOb+qICMrQC1fa0jP3JrR8RGJI4y61RoYvpnj6EbTmRKA==
+%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
+%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
%define with_threads 1
%define with_plugin 0
--
2.30.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Awk error when building tools on Mingw64
Hello Ryan,
I believe I have a different error than yours on a "Fedora Linux 35
Container" but my error is exactly at the same place as yours.
But to your problem:
It looks like the `$i` has been replaced nothing by substitution.
Compare the output:
At the top: `[...]match($i,\".*lpython.*\")[...]`
In the error message below: `[...]match(,".*lpython.*")[...]`
It looks like `awk` gets the command line without `$i`.
The problem is likely in file source-builder/config/gdb-common-1.cfg
line 111 and line 117. May I suggest to try to comment out line 117 and
118 with an `#` (or replace them somehow). Then the gdb should build.
The question is why the `$i` disappears? I have seen such things in
Makefiles. There, you would need to write `$$i` to prevent substitution.
Does "Mingw64" use an unusual `sh`? Maybe replacing all `sh` with a link
to `bash` solves this?
Greetings,
fk
On 3/17/22 15:55, Ryan Long wrote:
> Subject:
> Awk error when building tools on Mingw64
> From:
> Ryan Long
> Date:
> 3/17/22, 15:55
>
> To:
> devel@rtems.org
>
>
> Hello,
>
> I'm trying to build the Aarch64 tools on Mingw64. When building gdb, I
> am getting the following error.
>
> config: tools/rtems-gdb-10.cfg
> error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags
> | awk 'BEGIN{FS=\"
> \"}/python/{for(i=1;i \"lib\"substr($i,3)\"*\";}'": 1: awk: cmd. line:1: BEGIN{FS="
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1: ^ syntax error
> awk: cmd. line:1: BEGIN{FS="
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1: ^ 1 is invalid as number of arguments for match
>
> I made a file to store this command like so
>
> BEGIN {FS=" "}
>
> /python/ {
> for(i=1;i if(match($i,".*lpython.*"))
> print "lib"substr($i,3)"*"
> }
>
> and ran it with the command "python2-config --ldflags | awk -f
> test.awk". It produces "libpython2.7*" as the output. The only
> difference between the two is I took out the "\"s since it's not being
> run on the command line.
>
> Does anyone have any ideas what might be going on? And how do we go
> about fixing this when the solution is found?
>
> Thanks,
>
> Ryan
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone: +49-89-18 94 741 - 23
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: RTEMS-specific Newlib patches for aarch64
On 3/17/2022 10:43, Sebastian Huber wrote: On 17/03/2022 16:40, Kinsey Moore wrote: with current newlib (ed32020) This is not the current Newlib. There are a couple of build system patches on top of it. I guess the problem is that one location in the patch uses #include <...> and not #include "...'. Ah, I was looking at the github repo which is perpetually stale by a couple of days. I'll check the most recent one and get the patch updated. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS-specific Newlib patches for aarch64
On 17/03/2022 16:40, Kinsey Moore wrote: with current newlib (ed32020) This is not the current Newlib. There are a couple of build system patches on top of it. I guess the problem is that one location in the patch uses #include <...> and not #include "...'. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 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: RTEMS-specific Newlib patches for aarch64
On 3/17/2022 07:30, Kinsey Moore wrote: On 3/17/2022 05:00, Sebastian Huber wrote: Hello, the current Newlib build fails for aarch64 due to RTEMS-specific patches: CC libc/string/libc_a-wcscmp.o ../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: fatal error: ../asmdefs.h: No such file or directory 29 | #include <../asmdefs.h> | ^~ Why are these patches not in upstream Newlib? The only patch I'm aware of should be for ILP32 support in the hand-coded AArch64 assembly in newlib. The short answer as to why the patch isn't upstream is that newlib hasn't committed it yet. The longer answer is that the hand-coded AArch64 ASM in newlib is sourced from ARM's optimized-routines repository. I provided a patch to newlib's specifications at which point they suggested I get it committed upstream in the optimized-routines repo, first. I did that and then requested they pull the changes, but they were in the middle of a release cycle. Having the patch locally was the interim solution while we waited for that release to finish and for newlib to pull in the changes. I'll take a look and see what the current status on that is and what changes prompted the patch to break. I just rebuilt this on the current RTEMS6 GCC10 branch with current newlib (ed32020) and had no problems building it. It's odd that the file is missing given that it's newly written by the patch. What else is necessary to reproduce the build failure? Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: AW: Dependencies of PPS API in rtems-libbsd
> >> I guess you want to enable tc_poll_pps in struct timecounter as well? > > > > I didn't plan to do that but it can be done just removing some #ifndef, > > right? > > Is this handler not use for the PPS support? If it is currently unused, then > please let it disabled. Ok. For now I was working with interrupts but I guess that the same can be done with polling, that's for that handler. > > > > >> For what do you need the sleep() and wakeup() support? Is this only used > >> by the RFC 2783 PPS-API implementation? > > > > Yes, they are required by pps_fetch() and pps_event() > > > >> If you want to keep implement this in RTEMS, then you can convert > >> this to use a condition variable from or . > > > > Do you mean to add a condition variable, for example in struct pps_state, > > and to replace sleep() and wakeup() by wait and signal? It > is good idea if we don't want to use the first functions. > > Ok, it seems the pps_event() could be called by interrupt service routines. > In this case, you cannot use a mutex and condition > variables. > You have to use a thread queue directly. Use the thread queue ISR lock for > mutual exclusion. Use _Thread_queue_Enqueue() to > emulate sleep() and > _Thread_queue_Flush_critical() to emulate wakeup(). Check all critical > sections that they can be protected by an ISR lock (no blocking > calls and short). Is this even so if pps_event() calls signal or broadcast? Because pps_fetch() is the only function that is waiting (and locking a mutex). > > > > >> All the uses of sleep() and wakeup() need to be clearly identified and if > >> possible avoided. > > > > May I ask, what is the reason for avoiding them? > > The sleep() and wakeup() synchronization is nice, but not suitable for > real-time systems (use of hash tables). > > > > > What do you think about coping the functions lmax()/qmin() and the define > > for ENOIOCTL? For lmax()/qmin() I saw that the file > where are defined (libkern.h) is in libnetworking. Not sure what it is the > best option here, I don't like when the things are duplicated. > > Since you refer to libnetworking I guess you work with RTEMS 5. Please first > get it working on RTEMS 6 and then we think about a back > port. Yes, I'm working with RTEMS 5 but my next step is port the changes to RTEMS 6 and then submit the patches. > > > > > What about tvtohz(), which is defined in > > rtemsbsd/rtems/rtems-kernel-timesupport.c? tvtohz() is used for converting timeval to hz, which is required by msleep(), msleep_spin() and tsleep but because they are not used, tvtohz() is not needed. > > Maybe just copy the dependencies to kern_tc.c. Later we can try to move them > to shared locations if necessary. I did this for lmax(), qmin() and ENOIOCTL. Thanks for your answers. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Movement of confdefs instance into a static library
On 3/17/2022 08:35, Sebastian Huber wrote: On 17/03/2022 14:22, Kinsey Moore wrote: On 3/17/2022 00:39, Sebastian Huber wrote: Hello Kinsey, On 16/03/2022 22:57, Kinsey Moore wrote: Is moving the confdefs instance into a shared library supported and expected to work? yes, but the order in which the linker resolves the dependencies is very important. You have to make sure that the custom configuration is resolved before the default configuration. I was also able to resolve the linker errors by specifying some of the link flags multiple times or creating a linker group. These are ways to address the ordering. It would help if you can show the linker command lines and the error messages. The link command is: arm-rtems6-gcc testsuites/fstests/fserror/test.c.113.o -o/home/kinsey/rtems-development/rtems-ddci/build/arm/deos/testsuites/fstests/imfs_fserror.exe -Wl,-Bstatic -L. -ltestimfs -lrtemstest -lrtemscpu -lrtemsbsp -Wl,-Bdynamic -qrtems -march=armv7-a -mfpu=neon -mfloat-abi=hard -mthumb -gdwarf-2 -fPIC -Wl,--gc-sections -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/shared/start -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/deos/start -Wl,-call_shared -Wl,-no-undefined /desk/arm/lib/libkernel.so /desk/arm/lib/libdeos653pal.so -L/desk/arm/appbin -ltime-prl -lface653 -lgcc-so -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar I think the problem is that you don't use -qrtems and your start file has no dependency on a configuration symbol (for example _ISR_Stack_area_begin). You have to make sure that somehow the configuration in libtestimfs.a is pulled in. Ok, thanks. -qrtems is still present in that line just after the static link options, but I'll see if I can add a dependency in the start file. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Movement of confdefs instance into a static library
On 17/03/2022 14:22, Kinsey Moore wrote: On 3/17/2022 00:39, Sebastian Huber wrote: Hello Kinsey, On 16/03/2022 22:57, Kinsey Moore wrote: Is moving the confdefs instance into a shared library supported and expected to work? yes, but the order in which the linker resolves the dependencies is very important. You have to make sure that the custom configuration is resolved before the default configuration. I was also able to resolve the linker errors by specifying some of the link flags multiple times or creating a linker group. These are ways to address the ordering. It would help if you can show the linker command lines and the error messages. The link command is: arm-rtems6-gcc testsuites/fstests/fserror/test.c.113.o -o/home/kinsey/rtems-development/rtems-ddci/build/arm/deos/testsuites/fstests/imfs_fserror.exe -Wl,-Bstatic -L. -ltestimfs -lrtemstest -lrtemscpu -lrtemsbsp -Wl,-Bdynamic -qrtems -march=armv7-a -mfpu=neon -mfloat-abi=hard -mthumb -gdwarf-2 -fPIC -Wl,--gc-sections -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/shared/start -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/deos/start -Wl,-call_shared -Wl,-no-undefined /desk/arm/lib/libkernel.so /desk/arm/lib/libdeos653pal.so -L/desk/arm/appbin -ltime-prl -lface653 -lgcc-so -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar I think the problem is that you don't use -qrtems and your start file has no dependency on a configuration symbol (for example _ISR_Stack_area_begin). You have to make sure that somehow the configuration in libtestimfs.a is pulled in. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 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: Movement of confdefs instance into a static library
On 3/17/2022 00:39, Sebastian Huber wrote: Hello Kinsey, On 16/03/2022 22:57, Kinsey Moore wrote: Is moving the confdefs instance into a shared library supported and expected to work? yes, but the order in which the linker resolves the dependencies is very important. You have to make sure that the custom configuration is resolved before the default configuration. I was also able to resolve the linker errors by specifying some of the link flags multiple times or creating a linker group. These are ways to address the ordering. It would help if you can show the linker command lines and the error messages. The link command is: arm-rtems6-gcc testsuites/fstests/fserror/test.c.113.o -o/home/kinsey/rtems-development/rtems-ddci/build/arm/deos/testsuites/fstests/imfs_fserror.exe -Wl,-Bstatic -L. -ltestimfs -lrtemstest -lrtemscpu -lrtemsbsp -Wl,-Bdynamic -qrtems -march=armv7-a -mfpu=neon -mfloat-abi=hard -mthumb -gdwarf-2 -fPIC -Wl,--gc-sections -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/shared/start -L/home/kinsey/rtems-development/rtems-ddci/bsps/arm/deos/start -Wl,-call_shared -Wl,-no-undefined /desk/arm/lib/libkernel.so /desk/arm/lib/libdeos653pal.so -L/desk/arm/appbin -ltime-prl -lface653 -lgcc-so -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar The newly introduced linking flags toward the end are: -Wl,-call_shared -Wl,-no-undefined /desk/arm/lib/libkernel.so /desk/arm/lib/libdeos653pal.so -L/desk/arm/appbin -ltime-prl -lface653 -lgcc-so The first error is: /home/kinsey/rtems-development/tools/lib/gcc/arm-rtems6/10.3.1/../../../../arm-rtems6/bin/ld: ./librtemscpu.a(threadsetstate.c.59.o): in function `_Thread_Scheduler_get_home': /home/kinsey/rtems-development/rtems-ddci/build/arm/deos/../../../cpukit/include/rtems/score/threadimpl.h:1533: undefined reference to `_Scheduler_Table' The remainder can be found here: https://pbot.rmdir.de/DVjoVpxIMVsciAh69jzNuQ Thanks, Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: AW: Dependencies of PPS API in rtems-libbsd
On 16/03/2022 08:04, gabriel.moy...@dlr.de wrote: Hello Sebastian, On 15/03/2022 16:31, gabriel.moy...@dlr.de wrote: I'm working on enabling PPS support in RTEMS does this mean you want to define PPS_SYNC for kern_tc.c and kern_ntptime.c in RTEMS? yes I guess you want to enable tc_poll_pps in struct timecounter as well? I didn't plan to do that but it can be done just removing some #ifndef, right? Is this handler not use for the PPS support? If it is currently unused, then please let it disabled. For what do you need the sleep() and wakeup() support? Is this only used by the RFC 2783 PPS-API implementation? Yes, they are required by pps_fetch() and pps_event() If you want to keep implement this in RTEMS, then you can convert this to use a condition variable from or . Do you mean to add a condition variable, for example in struct pps_state, and to replace sleep() and wakeup() by wait and signal? It is good idea if we don't want to use the first functions. Ok, it seems the pps_event() could be called by interrupt service routines. In this case, you cannot use a mutex and condition variables. You have to use a thread queue directly. Use the thread queue ISR lock for mutual exclusion. Use _Thread_queue_Enqueue() to emulate sleep() and _Thread_queue_Flush_critical() to emulate wakeup(). Check all critical sections that they can be protected by an ISR lock (no blocking calls and short). All the uses of sleep() and wakeup() need to be clearly identified and if possible avoided. May I ask, what is the reason for avoiding them? The sleep() and wakeup() synchronization is nice, but not suitable for real-time systems (use of hash tables). What do you think about coping the functions lmax()/qmin() and the define for ENOIOCTL? For lmax()/qmin() I saw that the file where are defined (libkern.h) is in libnetworking. Not sure what it is the best option here, I don't like when the things are duplicated. Since you refer to libnetworking I guess you work with RTEMS 5. Please first get it working on RTEMS 6 and then we think about a back port. What about tvtohz(), which is defined in rtemsbsd/rtems/rtems-kernel-timesupport.c? Maybe just copy the dependencies to kern_tc.c. Later we can try to move them to shared locations if necessary. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 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: RTEMS-specific Newlib patches for aarch64
On 3/17/2022 05:00, Sebastian Huber wrote: Hello, the current Newlib build fails for aarch64 due to RTEMS-specific patches: CC libc/string/libc_a-wcscmp.o ../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: fatal error: ../asmdefs.h: No such file or directory 29 | #include <../asmdefs.h> | ^~ Why are these patches not in upstream Newlib? The only patch I'm aware of should be for ILP32 support in the hand-coded AArch64 assembly in newlib. The short answer as to why the patch isn't upstream is that newlib hasn't committed it yet. The longer answer is that the hand-coded AArch64 ASM in newlib is sourced from ARM's optimized-routines repository. I provided a patch to newlib's specifications at which point they suggested I get it committed upstream in the optimized-routines repo, first. I did that and then requested they pull the changes, but they were in the middle of a release cycle. Having the patch locally was the interim solution while we waited for that release to finish and for newlib to pull in the changes. I'll take a look and see what the current status on that is and what changes prompted the patch to break. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] GDB: Prefer Python 3 over 2
This fixes the build of a recent GDB version:
gdb/python/py-micmd.c: In function 'int
micmdpy_uninstall_command(micmdpy_object*)':
gdb/python/py-micmd.c:430:20: error: 'PyDict_GetItemWithError' was not declared
in this scope
PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
^~~
---
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..c7f3955 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.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: Support for test coverage analysis in RTEMS 6
Hello Jerzy,
Please see my answers below.
José
From: Jerzy Jaskuc
Sent: 17 de março de 2022 10:44
To: VALDEZ Jose
Cc: devel@rtems.org
Subject: Re: Support for test coverage analysis in RTEMS 6
Hi José,
This is exactly what I needed, thanks so much!
I'm able to generate the reports successfully.
[JV]: Good!
Just a few small questions:
I see that in `sparc-gr712rc-smp-user-qual.yml` there's a step to build
`qual-only` and a step for `qual-only-coverage`.
Do I need the steps for `qual-only` if I'm only interested in the coverage?
What exactly does it do?
[JV]: These two steps compile RTEMS: ‘qual-only’, normal compilation,
‘qual-only-coverage’, coverage compilation. In this configuration you run the
same tests in normal and coverage mode. It looks like you only want coverage,
but you should take into attention:
* If you want to remove the normal mode, then you need to adapt the
qual-tool accordingly
* In principle you shall run the tests in both modes. It may be the case
that in coverage mode the tests pass and in standard mode they fail (the
coverage introduces instrumented code, which might impact your
test/application). I recommend that you make sure that your tests pass in both
modes.
I do not know if you are aware, but the ‘qual-only’ RTEMS is a subset of the
full RTEMS with the space-qualified parts. You want to use this one or the full
RTEMS? If it is the later one, then the scripts need to be adapted to use the
full RTEMS version.
Another thing is that for me it will be useful if i can generate coverage for
existing tests + my tests, so I can sort of compare them.
I can see that there is `src/rtems-qual-only` but not
`src/rtems-qual-only-coverage`, which brings a question of how are executables
in `sparc-rtems6` directory for `-coverage` generated?
Will it work if I move my tests into `src/rtems-qual-only` and link them in
specs?
[JV]: the src/rtems-qual-only are the source files of RTEMS (qualified subset,
as described above). When compiling you generate the following:
* src/rtems-qual-only/build/sparc/gr712rc-qual-only: build products of the
qual-only build
* src/rtems-qual-only/build/sparc/gr712rc-qual-only-coverage: build
products of the qual-only-coverage build, includes the gcno files
* sparc-rtems6/gr712rc-qual-only: rtems libraries, normal mode (including
the testsuite executables)
* sparc-rtems6/gr712rc-qual-only-coverage: rtems libraries, coverage mode
(including the testsuite executables)
I think what you want is to generate coverage for your tests only. You can
include your source and then update the RTEMS scripts to compile your tests.
Alternatively, you can hack and compile your test apart and include the binary
alongside with the RTEMS testsuite binaries. To run only your test, you could
delete all the other test executables from the folder. Also you might adapt
run-local-target-qual-only.yml and run-local-target-qual-only-coverage.yml, the
field ignore-tests you can add the list of all RTEMS tests (or the tests you
want to ignore).
Thanks a lot for your help,
All the best!
Jerzy
On Wed, 16 Mar 2022 at 23:03, VALDEZ Jose
mailto:jose.val...@edisoft.pt>> wrote:
Hello Jerzy,
Actually, the same configuration can be adapted to run in SIS (which is what we
use most of the times). Inside the QDP you have the file
qual-tool/config-variants/sparc-gr712rc-smp-user-qual.yml. Change the file to
the following (you can copy and paste the content, replacing the current one):
build-directory: build-sparc-gr712rc-smp-user-qual
post-process-items:
- uid: /dirs/djf-svr-deploy/dir
path: /directory
action: set
value: ${/variant:/deployment-directory}/user_doc/djf/svr
- uid: /dirs/ddf-sdd-deploy/dir
path: /directory
action: set
value: ${/variant:/deployment-directory}/user_doc/ddf/sdd
- uid: /steps/build-djf-svr
path: /config-file
action: set
value: rtems/djf/svr/config_user.yml
- uid: /package-build
path: /links
action: set
value:
- role: build-step
uid: steps/build-bsp-qual-only
- role: build-step
uid: steps/build-bsp-qual-only-coverage
- role: build-step
uid: steps/run-local-target-qual-only
- role: build-step
uid: steps/run-local-target-qual-only-coverage
- role: build-step
uid: steps/build-ddf-sdd
- role: build-step
uid: steps/build-djf-svr
spec-paths:
- spec-spec
- spec-glossary
- config
Then follow the steps as described in section “11.3 Guidance for RTEMS
Qualification in User’s Environment” to generate your own SVR. After you have
this working example, it would be easier to see how the things work. The
scripts/configuration files in the qual-tool folder could be adapted to what
you want (i.e: just generate coverage for your tests). Feel free to ask me if
you have any difficulty!
Best regards
José
From: Jerzy Jaskuc mailto:jask...@tcd.ie>>
Sent: 16 de março de 2022 19:16
To: VALDEZ Jose mailto:jose.val...@edisoft.pt>>
Cc:
Re: Support for test coverage analysis in RTEMS 6
Hi José,
This is exactly what I needed, thanks so much!
I'm able to generate the reports successfully.
Just a few small questions:
I see that in `sparc-gr712rc-smp-user-qual.yml` there's a step to build
`qual-only` and a step for `qual-only-coverage`.
Do I need the steps for `qual-only` if I'm only interested in the coverage?
What exactly does it do?
Another thing is that for me it will be useful if i can generate coverage
for existing tests + my tests, so I can sort of compare them.
I can see that there is `src/rtems-qual-only` but not
`src/rtems-qual-only-coverage`, which brings a question of how are
executables in `sparc-rtems6` directory for `-coverage` generated?
Will it work if I move my tests into `src/rtems-qual-only` and link them in
specs?
Thanks a lot for your help,
All the best!
Jerzy
On Wed, 16 Mar 2022 at 23:03, VALDEZ Jose wrote:
> Hello Jerzy,
>
>
>
> Actually, the same configuration can be adapted to run in SIS (which is
> what we use most of the times). Inside the QDP you have the file
> qual-tool/config-variants/sparc-gr712rc-smp-user-qual.yml. Change the file
> to the following (you can copy and paste the content, replacing the current
> one):
>
>
>
> build-directory: build-sparc-gr712rc-smp-user-qual
>
> post-process-items:
>
> - uid: /dirs/djf-svr-deploy/dir
>
> path: /directory
>
> action: set
>
> value: ${/variant:/deployment-directory}/user_doc/djf/svr
>
> - uid: /dirs/ddf-sdd-deploy/dir
>
> path: /directory
>
> action: set
>
> value: ${/variant:/deployment-directory}/user_doc/ddf/sdd
>
> - uid: /steps/build-djf-svr
>
> path: /config-file
>
> action: set
>
> value: rtems/djf/svr/config_user.yml
>
> - uid: /package-build
>
> path: /links
>
> action: set
>
> value:
>
> - role: build-step
>
> uid: steps/build-bsp-qual-only
>
> - role: build-step
>
> uid: steps/build-bsp-qual-only-coverage
>
> - role: build-step
>
> uid: steps/run-local-target-qual-only
>
> - role: build-step
>
> uid: steps/run-local-target-qual-only-coverage
>
> - role: build-step
>
> uid: steps/build-ddf-sdd
>
> - role: build-step
>
> uid: steps/build-djf-svr
>
> spec-paths:
>
> - spec-spec
>
> - spec-glossary
>
> - config
>
>
>
> Then follow the steps as described in section “11.3 Guidance for RTEMS
> Qualification in User’s Environment” to generate your own SVR. After you
> have this working example, it would be easier to see how the things work.
> The scripts/configuration files in the qual-tool folder could be adapted to
> what you want (i.e: just generate coverage for your tests). Feel free to
> ask me if you have any difficulty!
>
>
>
> Best regards
>
>
>
> José
>
>
>
> *From:* Jerzy Jaskuc
> *Sent:* 16 de março de 2022 19:16
> *To:* VALDEZ Jose
> *Cc:* devel@rtems.org
> *Subject:* Re: Support for test coverage analysis in RTEMS 6
>
>
>
> Hi José,
>
>
>
> I'm aware of the QDP, although it is pretty big so I got confused and only
> followed `11.3 Guidance for RTEMS Qualification in User’s Environment`,
> which didn't work as I assume it needs actual board for tests to not
> be`Invalid`
>
> The reports generated are exactly what I'm looking for and steps you
> mentioned seems much more manageable!
>
>
>
> I can see gcno files and I can see gcda bytes within the logs of the test
> run.
>
> I will take a look at adapting the python scripts then.
>
>
>
> Thanks a lot for your help!
>
>
>
> All the best,
>
> Jerzy
>
>
>
>
>
>
>
> On Wed, 16 Mar 2022 at 17:05, VALDEZ Jose wrote:
>
> Hello Jerzy,
>
> Recently we concluded a project, the RTEMS SMP Qualification which also
> needed to gather coverage for RTEMS (which had the participation of Andrew
> Butterfield from TCD/LERO). I suggest that you take a look at
> https://rtems-qual.io.esa.int/, download one of the QDPs (maybe you want
> the GR712RC, SMP) and look for the docs/djf/svr document. There you may
> find the coverage folder, with the html coverage reports and in the svr.pdf
> the coverage summary table.
>
> If this is what you want for your test, I suggest to take a look at
> qual-tool/svrmanager.py and qual-tool/ccoverage_process.py.
>
> Basically for this what you need to do:
>
> * Compile RTEMS with coverage flags. This will generate the gcno files
> * Run your test, the reports should generate the gcda bytes (Sebastian
> Huber added support for coverage in RTEMS itself)
> * Use/adapt ccoverage_process.py to generate the coverage reports, which
> makes use of the gcovr tool.
>
> Hope this helps
>
> José
>
> -Original Message-
> From: devel On Behalf Of Jerzy Jaskuc
> Sent: 16 de março de 2022 16:46
> To: devel@rtems.org
> Subject: Support for test coverage analysis in RTEMS 6
>
> Hi,
>
> I've been looking into generating code coverage reports from RTEMS tests
> in RTEMS 6.
> I'm using SPARC with gr712rc BSP.
>
> I'm following the steps outlined in the coverage analysis documentation
> https://docs.rtems.org/branches/master/user/testing/coverage.html
>
> However, when I run it on
RTEMS-specific Newlib patches for aarch64
Hello, the current Newlib build fails for aarch64 due to RTEMS-specific patches: CC libc/string/libc_a-wcscmp.o ../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: fatal error: ../asmdefs.h: No such file or directory 29 | #include <../asmdefs.h> | ^~ Why are these patches not in upstream Newlib? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 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
