[PATCH v2] sppps01: Add test case for early returns of pps_event()
---
testsuites/sptests/sppps01/init.c | 49 +--
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/testsuites/sptests/sppps01/init.c
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..7779f7d9e7 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsuites/sptests/sppps01/init.c
@@ -46,6 +46,7 @@ const char rtems_test_name[] = "SPPPS 1";
struct test_pps_device {
struct pps_state pps;
rtems_id task_waiting;
+ int wokenup;
};
typedef struct {
@@ -59,9 +60,9 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
struct test_pps_device pps_dev;
struct pps_fetch_args fetch;
+ memset( &pps_dev, 0, sizeof( pps_dev ) );
pps_dev.task_waiting = RTEMS_INVALID_ID;
- memset( &pps_dev.pps, 0, sizeof( pps_dev.pps ) );
pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
pps_init_abi( &pps_dev.pps );
pps_dev.pps.ppsparam.mode = PPS_CAPTUREASSERT;
@@ -76,6 +77,48 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
T_eq_int( status, ETIMEDOUT );
}
+static void fake_wakeup(struct pps_state *pps)
+{
+ struct test_pps_device *pps_dev;
+
+ pps_dev = RTEMS_CONTAINER_OF( pps, struct test_pps_device, pps );
+ pps_dev->wokenup++;
+}
+
+T_TEST_CASE( PPSEventEarlyReturns )
+{
+ struct test_pps_device pps_dev;
+
+ memset( &pps_dev, 0, sizeof( pps_dev ) );
+ pps_dev.task_waiting = RTEMS_INVALID_ID;
+
+ pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
+ pps_init_abi( &pps_dev.pps );
+ pps_dev.pps.wakeup = fake_wakeup;
+ pps_dev.pps.ppsparam.mode = PPS_CAPTUREASSERT;
+
+ pps_capture( &pps_dev.pps );
+ /* Trigger event with a different event than the one previously selected */
+ pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+ T_eq_int( pps_dev.wokenup, 0 );
+
+ pps_dev.pps.ppsparam.mode = PPS_CAPTURECLEAR;
+
+ /* Wait th_generation to be updated */
+ rtems_task_wake_after(1);
+ pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+ T_eq_int( pps_dev.wokenup, 0 );
+
+ /* Save current timecounter in pps_state object */
+ pps_capture( &pps_dev.pps );
+ pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+ T_eq_int( pps_dev.wokenup, 0 );
+
+ pps_capture( &pps_dev.pps );
+ pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+ T_eq_int( pps_dev.wokenup, 1 );
+}
+
static void wakeup(struct pps_state *pps)
{
struct test_pps_device *pps_dev;
@@ -120,7 +163,7 @@ static void pps_task(rtems_task_argument arg)
sc = rtems_event_send( ctx->main_task, PPS_EVENT_RECEIVED );
T_rsc_success( sc );
- rtems_task_delete(rtems_task_self());
+ rtems_task_exit();
}
T_TEST_CASE( WakeupTaskWithPPSEvent )
@@ -134,11 +177,11 @@ T_TEST_CASE( WakeupTaskWithPPSEvent )
rtems_task_priority pps_task_prio = 1;
rtems_event_set out;
+ memset( &pps_dev, 0, sizeof( pps_dev ) );
pps_dev.task_waiting = RTEMS_INVALID_ID;
ctx.pps_dev = &pps_dev;
ctx.main_task = rtems_task_self();
- memset( &pps_dev.pps, 0, sizeof( pps_dev.pps ) );
pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
pps_init_abi( &pps_dev.pps );
pps_dev.pps.wait = wait;
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 4:25 pm, Sebastian Huber wrote: > On 01.07.22 08:22, Chris Johns wrote: I am encouraged by some of the generated code I have reviewed. I like what it does. >> I am a little lost with the difference between >> LIBRARY_OPTIMIZATION_FLAGS and >> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference >> between >> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can >> set >> from an INI file? > Currently the OPTIMIZATION_FLAGS are used for all code (code for > libraries and > code for tests). With this change you can build the libraries with -O0 > and > the > tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? >>> Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries >>> in >>> bsps and cpukit. >> Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming >> like >> BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was >> in >> the patch I would have understood exactly what they do. > > The BSP is just a library: librtemsbsp.a. I can split > LIBRARY_OPTIMIZATION_FLAGS > into BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS if this helps. I think it does. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 08:22, Chris Johns wrote: I am encouraged by some of the generated code I have reviewed. I like what it does. I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in bsps and cpukit. Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in the patch I would have understood exactly what they do. The BSP is just a library: librtemsbsp.a. I can split LIBRARY_OPTIMIZATION_FLAGS into BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS if this helps. -- 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: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 4:03 pm, Sebastian Huber wrote: > On 01.07.22 07:38, Chris Johns wrote: If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? >>> It is not per se specific to GCC. Maybe we should name it >>> RTEMS_COVERAGE_INSTRUMENTATION. >> What if another approach to instrumented coverage is developed? >> >> Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. > > Ok, I rename it to RTEMS_GCOV_COVERAGE. Thanks. > The user can fine tune the build through the > LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and > COVERAGE_COMPILER_FLAGS, > COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? >>> Do you have to specify the compiler flags also during linking if you use >>> LTO? >> You add `-flto -ffat-lto-objects` to build the object files so they then >> contain >> the data the lto pass in the linker needs to optimise across the object >> files. > > The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to pass > the > compiler flags during linking if you use LTO? Good question, I do not know. I think you can tall the linker to use LTO and to not use LTO. I do not know what the default mode of the linker is when presented with LTO enabled object files? The app I am building sets these flags in the cflags and those are passed to the linker. >> I am encouraged by some of the generated code I have reviewed. I like what it >> does. >> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? >>> Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries >>> and >>> code for tests). With this change you can build the libraries with -O0 and >>> the >>> tests with -O2 for example. >> Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? > > Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in > bsps and cpukit. Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in the patch I would have understood exactly what they do. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 08/12] gcov: Add functions to dump the gcov information
On 1/7/2022 3:59 pm, Sebastian Huber wrote: > On 01.07.22 07:48, Chris Johns wrote: >> On 1/7/2022 3:00 pm, Sebastian Huber wrote: >>> On 01.07.22 02:37, Chris Johns wrote: > +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); > + Why just a per char interface? Given this is in the score a buffer plus length interface would make more sense? It would make the interface more efficient. >>> >>> All the test output uses a single char output function. This is also used by >>> _IO_Base64(). >> >> That is a shame. Are you saying it is a lot of work to change? > > I don't see a need for change. These are internal functions. They are not part > of the API. These types of patches load functionality into the score that is required to be maintained and yet it is limited in scope in a small and simple way. I see some of these things as powerful and a benefit to a wider part of the community and it is exciting to see this happening. I am raising these questions and probing what is being offered so we can understand the limitations and possibly what might be needed. The per char could be a convenience function version of the buffer and length call for those use cases than want it, ie > +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg ) >>> >>> If you really need this, you can call the libgcov functions directly. >> >> The title of this patch to the "score" says ... >> >> "gcov: Add functions to dump the gcov information" >> >> If I have a large app and want to use this support am I restricted to a per >> character interface rather than a buffer and length or I implement this again >> directly? I am not sure I understand the purpose of this code in the score? > > The purpose of the score functions are to provide an implementation for > rtems_test_gcov_dump_info(). The RTEMS test suite simply requires a character > output function. Yes the testsuite is limited to a per char output path. I had missed the scoping with `rtems_test_*`. >> Is ESA going to use this gcov coverage for their applications? > > They used gcov in the past with lots of local hacks. > >> >>> I can move the linker set definition to a separate file. >> >> I do not know how this relates. > > If we move the RTEMS_LINKER_ROSET( gcov_info, const struct gcov_info * ); > definition to a separate file, you can use __gcov_info_to_gcda() in your > application with a custom dump function. If that provides a path we can work towards better support for applications then I think that would be a good thing to do. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 07:38, Chris Johns wrote: If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? It is not per se specific to GCC. Maybe we should name it RTEMS_COVERAGE_INSTRUMENTATION. What if another approach to instrumented coverage is developed? Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. Ok, I rename it to RTEMS_GCOV_COVERAGE. The user can fine tune the build through the LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? Do you have to specify the compiler flags also during linking if you use LTO? You add `-flto -ffat-lto-objects` to build the object files so they then contain the data the lto pass in the linker needs to optimise across the object files. The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to pass the compiler flags during linking if you use LTO? I am encouraged by some of the generated code I have reviewed. I like what it does. I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in bsps and cpukit. -- 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: [PATCH] irq/arm-gicv3.h: Enable interrupt groups 0 and 1
On 28/6/2022 1:14 pm, Kinsey Moore wrote:
> On 6/26/2022 22:37, Chris Johns wrote:
>> On 24/6/2022 7:43 pm, Sebastian Huber wrote:
>>> The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4
>>> define) and AArch64 targets. Use the existing WRITE_SR() abstraction to
>>> access
>>> the interrupt group 0 and 1 enable registers. This fixes the build for the
>>> AArch32 target.
>> It needs to be tested on hardware before I am OK with it. It also needs EL3
>> firmware, ie TF-A, to correctly initialise a system.
>>
>> I would be OK with qemu if it can be shown it honours the security level
>> correctly. I however have no time to determine this as I have Versal hardware
>> that did not like the changes.
> I, unfortunately, have no way to test this on hardware but I would agree. I
> would not be inclined to trust qemu in this regard.
>>> ---
>>> bsps/include/dev/irq/arm-gicv3.h | 23 ++-
>>> 1 file changed, 6 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/bsps/include/dev/irq/arm-gicv3.h
>>> b/bsps/include/dev/irq/arm-gicv3.h
>>> index a79368ebdf..7db7bad034 100644
>>> --- a/bsps/include/dev/irq/arm-gicv3.h
>>> +++ b/bsps/include/dev/irq/arm-gicv3.h
>>> @@ -116,9 +116,11 @@ extern "C" {
>>> #else /* ARM_MULTILIB_ARCH_V4 */
>>> /* AArch64 GICv3 registers are not named in GCC */
>> The FreeBSD would suggest this is not entirely true? May be it is for
>> aarch32?
> IIRC, a select few were named and usable in GCC, but the vast majority were
> not.
> This may have gotten better with more recent GCC releases since this comment
> was
> written more than 2 years ago.
>>
>>> -#define ICC_IGRPEN0 "S3_0_C12_C12_6, %0"
>>> -#define ICC_IGRPEN1 "S3_0_C12_C12_7, %0"
>>> +#define ICC_IGRPEN0_EL1 "S3_0_C12_C12_6, %0"
>>> +#define ICC_IGRPEN1_EL1 "S3_0_C12_C12_7, %0"
>> This looks like it is only a label change and so it is the same opcode. Is
>> that
>> correct?
> According to the ARMv8 TRM, this is the full proper name for it.
>>
>>> #define ICC_IGRPEN1_EL3 "S3_6_C12_C12_7, %0"
>>> +#define ICC_IGRPEN0 ICC_IGRPEN0_EL1
>>> +#define ICC_IGRPEN1 ICC_IGRPEN1_EL1
>>> #define ICC_PMR "S3_0_C4_C6_0, %0"
>>> #define ICC_EOIR1 "S3_0_C12_C12_1, %0"
>>> #define ICC_SRE "S3_0_C12_C12_5, %0"
>>> @@ -300,20 +302,6 @@ static void gicv3_init_dist(volatile gic_dist *dist)
>>> }
>>> }
>>> -/*
>>> - * A better way to access these registers than special opcodes
>>> - */
>>> -#define isb() __asm __volatile("isb" : : : "memory")
>>> -
>>> -#define WRITE_SPECIALREG(reg, _val) \
>>> - __asm __volatile("msr " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
>>> -
>>> -#define gic_icc_write(reg, val) \
>>> -do { \
>>> - WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
>>> - isb(); \
>>> -} while (0)
>>> -
>>> static void gicv3_init_cpu_interface(uint32_t cpu_index)
>>> {
>>> uint32_t sre_value = 0x7;
>>> @@ -335,7 +323,8 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
>>> }
>>> /* Enable interrupt groups 0 and 1 */
>>> - gic_icc_write(IGRPEN1, 1);'
>> This has been tested and works on a Versal.
>>
>>> + WRITE_SR(ICC_IGRPEN0, 0x1);
>> This crashed in EL1 on a Versal with 2021.2 TF-A.
>>
>> Why do you need to set this here?
>>
>>> + WRITE_SR(ICC_IGRPEN1, 0x1);
>> This instruction also generated an exception. It has been a while but I am
>> pretty sure I had to comment this one and when I did no interrupts happened.
>> The
>> code I ported from FreeBSD worked.
>>
>> I also think the FreeBSD calls are easier to review and so maintain. I find
>> those ARM type registers difficult to find and check.
> The opcode S3_0_C12_C12_7 should be identical in behavior and assembly with
> the
> name ICC_IGRPEN1_EL1. It's spelled out in the ARMv8 TRM on D12-3006.
I will take a look once the hardware becomes available to me.
I could be mistaken with that piece of the change but I seem to remember both
enable writes causing an issue and no writes resulting in no interrupts.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 08/12] gcov: Add functions to dump the gcov information
On 01.07.22 07:48, Chris Johns wrote: On 1/7/2022 3:00 pm, Sebastian Huber wrote: On 01.07.22 02:37, Chris Johns wrote: +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); + Why just a per char interface? Given this is in the score a buffer plus length interface would make more sense? It would make the interface more efficient. All the test output uses a single char output function. This is also used by _IO_Base64(). That is a shame. Are you saying it is a lot of work to change? I don't see a need for change. These are internal functions. They are not part of the API. The per char could be a convenience function version of the buffer and length call for those use cases than want it, ie +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg ) If you really need this, you can call the libgcov functions directly. The title of this patch to the "score" says ... "gcov: Add functions to dump the gcov information" If I have a large app and want to use this support am I restricted to a per character interface rather than a buffer and length or I implement this again directly? I am not sure I understand the purpose of this code in the score? The purpose of the score functions are to provide an implementation for rtems_test_gcov_dump_info(). The RTEMS test suite simply requires a character output function. Is ESA going to use this gcov coverage for their applications? They used gcov in the past with lots of local hacks. I can move the linker set definition to a separate file. I do not know how this relates. If we move the RTEMS_LINKER_ROSET( gcov_info, const struct gcov_info * ); definition to a separate file, you can use __gcov_info_to_gcda() in your application with a custom dump function. -- 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: [PATCH 08/12] gcov: Add functions to dump the gcov information
On 1/7/2022 3:00 pm, Sebastian Huber wrote: > On 01.07.22 02:37, Chris Johns wrote: >>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); >>> + >> Why just a per char interface? Given this is in the score a buffer plus >> length >> interface would make more sense? It would make the interface more efficient. > > All the test output uses a single char output function. This is also used by > _IO_Base64(). That is a shame. Are you saying it is a lot of work to change? >> The per char could be a convenience function version of the buffer and length >> call for those use cases than want it, ie >> >>> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg ) > > If you really need this, you can call the libgcov functions directly. The title of this patch to the "score" says ... "gcov: Add functions to dump the gcov information" If I have a large app and want to use this support am I restricted to a per character interface rather than a buffer and length or I implement this again directly? I am not sure I understand the purpose of this code in the score? Is ESA going to use this gcov coverage for their applications? > I can move the linker set definition to a separate file. I do not know how this relates. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 3:07 pm, Sebastian Huber wrote: > On 01.07.22 03:19, Chris Johns wrote: >> On 29/6/2022 4:30 pm, Sebastian Huber wrote: >>> This patch set adds support to build the RTEMS libraries with gcov >>> instrumentation to get code and branch coverage. There are some >>> improvements >>> necessary in the build system to support different compiler flags for >>> libraries >>> and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE >>> build configuration option. >> >> Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow >> provides? > > The covoar uses uninstrumented code, so these two approaches are orthogonal. > You > could even use both approaches at the same time. This makes little sense, but > you could do it. Agreed, it does not make sense. Someone new to RTEMS would not know what this all means and may think they need to enable the option for any type of coverage. >> If this enable is specific to GCC's gcov then maybe we should clearly label >> it >> as that and avoid overloading the term and any possible confusion that might >> bring. For example RTEMS_GCOV_CONVERGE? > > It is not per se specific to GCC. Maybe we should name it > RTEMS_COVERAGE_INSTRUMENTATION. What if another approach to instrumented coverage is developed? Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. >>> The user can fine tune the build through the >>> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and >>> COVERAGE_COMPILER_FLAGS, >>> COVERAGE_LINKER_FLAGS options. >> >> How would the LTO fat options be added? Would the pattern for >> COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? > > Do you have to specify the compiler flags also during linking if you use LTO? You add `-flto -ffat-lto-objects` to build the object files so they then contain the data the lto pass in the linker needs to optimise across the object files. I am encouraged by some of the generated code I have reviewed. I like what it does. >> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and >> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between >> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set >> from an INI file? > > Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and > code for tests). With this change you can build the libraries with -O0 and > the > tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? >> I think the changes to cppflags, cflags and cxxflags are nice and a great >> progression. >> >>> The gcov information is dumped after each test >>> case in a base64 encoded gcfn and gcda data stream. It looks like this: >>> >>> *** BEGIN OF GCOV INFO BASE64 *** >>> bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp >>> dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB >>> DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA >>> ... >>> srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc >>> ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 >>> wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= >>> *** END OF GCOV INFO BASE64 *** >>> >>> On the host you can decode the block and pipe it through the gcov-tool to >>> produce the *.gcda files. Example Python code: >>> >>> block = some regex stuff to get the block between the BEGIN/END OF ... >>> stream = base64.b64decode(block) >>> subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) >> >> Nice. Could rtems-test detect this and then run that command if available? > > Yes, this could be an option. Another is to produce a JSON report and then > run a > second script. Sure. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 03:19, Chris Johns wrote: On 29/6/2022 4:30 pm, Sebastian Huber wrote: This patch set adds support to build the RTEMS libraries with gcov instrumentation to get code and branch coverage. There are some improvements necessary in the build system to support different compiler flags for libraries and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE build configuration option. Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow provides? The covoar uses uninstrumented code, so these two approaches are orthogonal. You could even use both approaches at the same time. This makes little sense, but you could do it. If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? It is not per se specific to GCC. Maybe we should name it RTEMS_COVERAGE_INSTRUMENTATION. The user can fine tune the build through the LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? Do you have to specify the compiler flags also during linking if you use LTO? I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. I think the changes to cppflags, cflags and cxxflags are nice and a great progression. The gcov information is dumped after each test case in a base64 encoded gcfn and gcda data stream. It looks like this: *** BEGIN OF GCOV INFO BASE64 *** bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA ... srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= *** END OF GCOV INFO BASE64 *** On the host you can decode the block and pipe it through the gcov-tool to produce the *.gcda files. Example Python code: block = some regex stuff to get the block between the BEGIN/END OF ... stream = base64.b64decode(block) subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) Nice. Could rtems-test detect this and then run that command if available? Yes, this could be an option. Another is to produce a JSON report and then run a second script. -- 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: [PATCH 08/12] gcov: Add functions to dump the gcov information
On 01.07.22 02:37, Chris Johns wrote: +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg ); + Why just a per char interface? Given this is in the score a buffer plus length interface would make more sense? It would make the interface more efficient. All the test output uses a single char output function. This is also used by _IO_Base64(). The per char could be a convenience function version of the buffer and length call for those use cases than want it, ie +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg ) If you really need this, you can call the libgcov functions directly. I can move the linker set definition to a separate file. -- 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: [PATCH 04/12] build: Improve value substitution
On 01.07.22 02:18, Chris Johns wrote:
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
The waf build system uses lists for tool flags. The build items may use
variable substitution. Add the ability to use the variable substitution in
lists. For example:
MORE_FLAGS = ['-more', '-flags']
flags:
- -some-flag
- ${MORE_FLAGS}
Before this change, the ${MORE_FLAGS} was substituted to "-more -flags". This
would be passed by waf as a single command line argument to the tool.
After this change, the ${MORE_FLAGS} list extends the flags list:
flags = ['-some-flag', '-more', '-flags']
This list extension is performed if a list element consists of exactly one
variable.
Is nesting supported?
You mean lists of lists? Yes, this would work, but we don't have lists
of lists in the build system.
The variable substitution in general is not recursive currently.
--
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: [PATCH 00/12] Support gcov instrumentation
On 29/6/2022 4:30 pm, Sebastian Huber wrote: > This patch set adds support to build the RTEMS libraries with gcov > instrumentation to get code and branch coverage. There are some improvements > necessary in the build system to support different compiler flags for > libraries > and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE > build configuration option. Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow provides? If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? > The user can fine tune the build through the > LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and > COVERAGE_COMPILER_FLAGS, > COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? I think the changes to cppflags, cflags and cxxflags are nice and a great progression. > The gcov information is dumped after each test > case in a base64 encoded gcfn and gcda data stream. It looks like this: > > *** BEGIN OF GCOV INFO BASE64 *** > bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp > dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB > DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA > ... > srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc > ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 > wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= > *** END OF GCOV INFO BASE64 *** > > On the host you can decode the block and pipe it through the gcov-tool to > produce the *.gcda files. Example Python code: > > block = some regex stuff to get the block between the BEGIN/END OF ... > stream = base64.b64decode(block) > subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) Nice. Could rtems-test detect this and then run that command if available? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 08/12] gcov: Add functions to dump the gcov information
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> Update #4670.
> ---
> cpukit/include/rtems/score/io.h | 4 +
> cpukit/include/rtems/test-info.h| 6 ++
> cpukit/libtest/testgcovdumpinfo.c | 66 ++
> cpukit/score/src/iogcovdumpinfo.c | 101 +
> cpukit/score/src/iogcovdumpinfobase64.c | 111
> spec/build/cpukit/librtemscpu.yml | 2 +
> spec/build/cpukit/librtemstest.yml | 1 +
> testsuites/validation/tc-terminate.c| 3 +-
> 8 files changed, 293 insertions(+), 1 deletion(-)
> create mode 100644 cpukit/libtest/testgcovdumpinfo.c
> create mode 100644 cpukit/score/src/iogcovdumpinfo.c
> create mode 100644 cpukit/score/src/iogcovdumpinfobase64.c
>
> diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
> index 106418f185..097cb9bdfe 100644
> --- a/cpukit/include/rtems/score/io.h
> +++ b/cpukit/include/rtems/score/io.h
> @@ -141,6 +141,10 @@ int _IO_Base64url(
> */
> void _IO_Relax( void );
>
> +void _IO_Gcov_dump_info( IO_Put_char put_char, void *arg );
> +
> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
> +
Why just a per char interface? Given this is in the score a buffer plus length
interface would make more sense? It would make the interface more efficient.
The per char could be a convenience function version of the buffer and length
call for those use cases than want it, ie
> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )
> +{
> + IO_Gcov_context *ctx;
> + IO_Put_char put_char;
> + void*ctx_arg;
> + const char *in;
> + const void *end;
> +
> + ctx = arg;
> + in = data;
> + end = in + length;
> + put_char = ctx->put_char;
> + ctx_arg = ctx->arg;
> +
> + while ( in != end ) {
> +( *put_char )( *in, ctx_arg );
> +++in;
> + }
> +}
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 04/12] build: Improve value substitution
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> The waf build system uses lists for tool flags. The build items may use
> variable substitution. Add the ability to use the variable substitution in
> lists. For example:
>
> MORE_FLAGS = ['-more', '-flags']
>
> flags:
> - -some-flag
> - ${MORE_FLAGS}
>
> Before this change, the ${MORE_FLAGS} was substituted to "-more -flags". This
> would be passed by waf as a single command line argument to the tool.
>
> After this change, the ${MORE_FLAGS} list extends the flags list:
>
> flags = ['-some-flag', '-more', '-flags']
>
> This list extension is performed if a list element consists of exactly one
> variable.
Is nesting supported?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/xilinx-zynq: Init debug console only once
OK and thanks
Chris
On 29/6/2022 12:19 am, Sebastian Huber wrote:
> Initialize the debug console only once during early system initialization.
> ---
> bsps/arm/xilinx-zynq/console/debug-console.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c
> b/bsps/arm/xilinx-zynq/console/debug-console.c
> index 0e9b756f30..1423708bb7 100644
> --- a/bsps/arm/xilinx-zynq/console/debug-console.c
> +++ b/bsps/arm/xilinx-zynq/console/debug-console.c
> @@ -52,10 +52,7 @@ static void zynq_debug_console_init(void)
>
> static void zynq_debug_console_early_init(char c)
> {
> - rtems_termios_device_context *base =
> -&zynq_uart_instances[BSP_CONSOLE_MINOR].base;
> -
> - zynq_uart_initialize(base);
> + zynq_debug_console_init();
>zynq_debug_console_out(c);
> }
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Congratulations to Two Core Developers
Gedare and Hesham ... congratulations, this is fantastic news. I know there has been a lot of work in these achievements and they are well deserved. Chris On 29/6/2022 12:23 am, Joel Sherrill wrote: > Hi > > I'd like to congratulate two RTEMS core developers on recent significant > achievements. > > (1) Gedare Bloomwas granted tenure at the University of Colorado at Colorado > Springs. > > (2) Hesham Almatary has passed his Ph.D. viva/orals and is nearing graduation. > > These are both major life events and the RTEMS Community would like to > congratulate them. > > --joel > > ___ > 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: Integrating the Formal Methods part of Qualification
On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie wrote: > Dear RTEMS Developers, > > While the validation tests from the RTEMS pre-qualification activity are > now merged into the RTEMS master, the work done in investigating and > deploying formal methods techniques is not yet merged. > > The activity had two main phases: a planning phase (Nov 2018-Oct 2019) > that explored various formal techniques, followed by an execution phase > (Oct 2019-Nov 2021) that then applied selected techniques to selected > parts of RTEMS. Some discussions occurred with the RTEMS community > via the mailings lists over this time. A short third phase (Nov 2021 - Dec > 2021) > then reported on the outcomes. Each phase resulted in a technical report. > > The key decision made was to use Promela/SPIN for test generation, and > to apply it to the Chains API, the Event Manager, and the SMP scheduler > thread queues. This involved developing models in the Promela language > and using the SPIN model-checker tool to both check their correctness > and to generate execution scenarios that could be used to generate tests. > Tools were developed using Python 3.8 to support this. Initial documentation > about tools and how to use them was put into the 2nd phase report. Congratulations for the work and results you and others have managed to achieve. It is exciting to see this happening with RTEMS and being made public. > We now come to the part where we explore the best way to integrate this > into RTEMS. I am proposing to do this under the guidance of Sebastian Huber. > > The first suggested step is adding in new documentation to the RTEMS > Software Engineering manual, as a new Formal Methods chapter. This would > provide some motivation, as well as a "howto". > > I assume that I would initially describe the proposed changes using the patch > review process described in the section on Preparing and Sending Patches in > the User Manual. > > How do you feel I should best proceed? It is hard for me to answer until I understand what is being submitted and who maintains it? I am sure you understand this due to the specialised nature of the work. What will be submitted, ie SPIN files, scripts, etc? Where are you looking to add these pieces? How is the verification run against the code? Do we manage regression testing and is that even possible? I hope my simple questions highlight a lack of understand on how this works and how we maintain it and use it once integrated. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] arm/gicv3: Fix building arm/r52
On 30/6/2022 1:42 am, Sebastian Huber wrote: > On 27/06/2022 08:27, Sebastian Huber wrote: >> On 27/06/2022 05:02, Chris Johns wrote: >>> On 24/6/2022 7:44 pm, Sebastian Huber wrote: On 20.06.22 04:03, chr...@rtems.org wrote: > From: Chris Johns > > --- > bsps/include/dev/irq/arm-gicv3.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/bsps/include/dev/irq/arm-gicv3.h > b/bsps/include/dev/irq/arm-gicv3.h > index a79368ebdf..aac02fa191 100644 > --- a/bsps/include/dev/irq/arm-gicv3.h > +++ b/bsps/include/dev/irq/arm-gicv3.h > @@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t > cpu_index) > } > /* Enable interrupt groups 0 and 1 */ > +#ifdef ARM_MULTILIB_ARCH_V4 > + WRITE_SR(ICC_IGRPEN0, 0x1); > + WRITE_SR(ICC_IGRPEN1, 0x1); > +#else > gic_icc_write(IGRPEN1, 1); > +#endif > WRITE_SR(ICC_CTLR, 0x0); > } I have a different patch to fix this: https://lists.rtems.org/pipermail/devel/2022-June/072056.html >>> >>> Does this change work on a real aarch64 with a suitably configured TF-A? The >>> security profile of the TF-A needs to disable EL1 access to these registers >>> to >>> see the issue. >> >> I don't have a hardware to test this change. I can do tests on a Cortex-R52 >> hardware. >> >> For the Cortex-R52, group 0 interrupts are signaled through FIQ exceptions >> and >> group 1 interrupts are signaled through IRQ exceptions. This processor has no >> secore/non-secure states. > > I checked the GICv3 manual. The group 0 interrupts are always Secure if the > system has at least two Security states. So, if RTEMS runs in Non-Secure mode, > it cannot modify group 0 interrupts. Thanks, this was my understanding once the exceptions made me take a look. > We have some things to consider: > > 1. Count of system security states I think there are registers available that detail this but I have not checked in detail what can be read and when. I prefer we avoid any runtime management. > 2. In which state RTEMS runs We have to be able to run non-secure in EL1. The FPD scalar cores (A72) on the Versal require this. I take that requirement as saying we should keep away from anything that relates to secure operations even for those cores that allow open access. FreeBSD and Linux do not touch these registers and I think that is a wise path to follow. > 3. What RTEMS needs to initialize We have to assume this is handled by the code that is responsible for establishing the secure state. For those cores that do not have or require a vertical software stack it may be OK for the BSP may hold that configuration. > We cannot simply use the target architecture to determine what to do during > GIC > initialization. Does the GiC need to handle this? > I think we need some BSP options to control the initialization behaviour. I am not sure this should be the responsibility of the BSP and RTEMS. I see it as something the boot loaders and boot process should manage. For the ZynqMP and Versal this and much much more is covered by TF-A. I recommend using TF-A for the Versal simply because of support ARM provides in it ... INFO:GICv3 with legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:BL31: Initializing runtime services WARNING: BL31: cortex_a72: CPU workaround for 859971 was missing! WARNING: BL31: cortex_a72: CPU workaround for 1319367 was missing! INFO:BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied INFO:BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied I prefer we do not attempt to get involved and complicate what this code is doing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [tools] tester: Normalize JSON and YAML reports
On 30/6/2022 4:34 pm, Sebastian Huber wrote:
> On 30/06/2022 07:58, Sebastian Huber wrote:
>> On 29/06/2022 17:54, Kinsey Moore wrote:
>>> On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
>
>> On 29 Jun 2022, at 4:42 pm, Sebastian Huber
>> wrote:
>>
>> On 29/06/2022 08:40, Sebastian Huber wrote:
>>> Report the same data in JSON and YAML reports. Do not report redundant
>>> information.
>>> Update 4671.
>>
>> This patch changes the JSON reports. Are there already consumers for the
>> JSON reports so that we have to be backward compatible?
>
> Could compatibility be added back in if this proves to be an issue?
>
> I am wondering if that could be considered if comparability becomes an
> issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators already
exist.
The existing attribute names are quite inconsistent, for example "Command
Line", "passed_count", "wrong-version_count". I would use lower case only
with "-" as a separator. The JSON report should contain all information of
a
test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4
(Linux
lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC 2022
(2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic -net
none
-serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M -kernel
build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1 for
0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2 for
0x214480.",
"GLOBAL: Hey I'm in derived class constructor number 3 for
0x214480.",
"LOCAL: Hey I'm in base class constructor number 4 for
0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
>>> There are no publicly available report generators for the existing format,
>>> but I do have one I use to generate STR documents for delivery using
>>> mustache
>>> templates and further processing. The existing format was designed to be
>>> easily consumable by that and other simple templating mechanisms by
>>> providing
>>> structure (test subsets) and p
Re: [tools] tester: Normalize JSON and YAML reports
On 6/30/2022 01:34, Sebastian Huber wrote:
On 30/06/2022 07:58, Sebastian Huber wrote:
On 29/06/2022 17:54, Kinsey Moore wrote:
On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports. Do not report
redundant
information.
Update 4671.
This patch changes the JSON reports. Are there already consumers
for the JSON reports so that we have to be backward compatible?
Could compatibility be added back in if this proves to be an issue?
I am wondering if that could be considered if comparability
becomes an issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators
already exist.
The existing attribute names are quite inconsistent, for example
"Command Line", "passed_count", "wrong-version_count". I would use
lower case only with "-" as a separator. The JSON report should
contain all information of a test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host":
"Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 (Linux
lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC
2022 (2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no
peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no
peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1
for 0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2
for 0x214480.",
"GLOBAL: Hey I'm in derived class constructor
number 3 for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4
for 0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
There are no publicly available report generators for the existing
format, but I do have one I use to generate STR documents for
delivery using mustache templates and further processing. The
existing format was designed to be easily consumable by that and
other simple templating mechanisms by providing structure (test
subsets) and precalculating values that would otherwise be implicit
in the data. Changes to the names of various fields should be easy
to accommodate, but a more significant restructure is going to
present problems continuing with any simple templating mechanism and
would instead require a more comprehensive document generator for
all cases.
I'm not necessarily opposed to this change as it significantly
simplifies the report generation code, but it will definitely
require some rework in my processes. I can't speak for any users of
the YAML repo
Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails
On 30/06/2022 09:52, Alexandre Oliva via Gcc-patches wrote: On Jun 27, 2022, Alexandre Oliva wrote: I see two potential ways to avoid this: Another possibility occurred to me: seeking back to the entry we're about to remove, before removing it. Then, POSIX-compliant implementations will just skip the removed entry and find the next one, while RTEMS will find the next entry at the spot where the removed entry used to be. It is syscall-heavier, and it may invoke O(n^2) behavior for each directory in remove_all, since prev_pos is quite likely to always hold the initial offset, requiring scanning past more and more removed entries after each removal, so I don't submit this formally for inclusion, but post it FTR. I've only confirmed that it solves the problem on RTEMS, passing libstdc++ filesystem test, but I haven't tested it further. From my point of view this is behaviour is an RTEMS bug. Instead of adding tweaks for RTEMS, it would be better to report the issues and fix them in RTEMS. It could be also a Newlib issue. -- 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
