Re: Remaining Waf Conversion Tickets for Community and GSoC Students

[Sebastian Huber]

On 11/02/2021 00:20, Chris Johns wrote:


On 10/2/21 4:20 pm, Sebastian Huber wrote:

On 08/02/2021 10:40, Chris Johns wrote:

It is written in Python 3.6.

We still need to support python 2. Maybe having this file support both could be
part of the project.

I think this BSP builder is a development tool which can use Python 3. It is
useful to maintain RTEMS, but it is not a tool required for end users of RTEMS
to develop applications. Independent of this, the Python 2 end of life was a
year ago.

This idea has real merit and it is pragmatic. Keeping rtems-central as python3
makes sense and it also makes sense to not pollute it with python2 code.

Sebastian are you able to have rtems-central export the needed files to the
rtemstoolkit in rtems-tools?


One option is to simply copy

https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

to somewhere in rtems-tools. This module depends on the yaml module.

Another option would be to use a special waf command (similar to 
bsp_defaults), to output the information for the BSP builder in JSON format.


--
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: Remaining Waf Conversion Tickets for Community and GSoC Students

[Sebastian Huber]

On 11/02/2021 00:30, Chris Johns wrote:


No source code change for Kinsey's BSPs -- just different GCC settings.

Do these settings change the ABI? I think we need to be careful having options
to vary a BSP's ABI with the same name.
Yes, I think each ABI variant of a BSP should have its own name. This is 
also important to test. Different instruction sets may produce different 
internal compiler errors.


--
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: Revisiting Minimum with Static Allocation

[Sebastian Huber]

On 10/02/2021 21:36, Gedare Bloom wrote:




On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill > wrote:


Hi

The minimum sample is intended to show how to construct the
minimum footprint RTEMS application. I suspect that with
Sebastian's recent work on static allocation and reducing
footprint, the minimum sample may be able to benefit from tweaking.

I just checked rtl22xx_t and it is < 16K code and 272 bytes of
data. :)

Hello tends to be in the 64K range. Perhaps a static allocation
hello variant.

Just wanting users to have good examples. A discussion at the
Flight Software Workshop mentioned RTEMS was big but it doesn't
seem to be if you look at executables which reflect those minimum
feature sets.

Hoping Sebastian has magic settings to apply so these numbers are
as good as possible.

This is a good idea. A "useful" minimum configuration with static 
objects, or maybe even a couple of them, could be helpful to identify 
reasonable bottom ends of the spectrum we can conceivably support.


For the pre-qualification project we have to deliver some resource usage 
information. We would like to provide some benchmark programs and some 
rules to estimate the resource usage based on configuration options. 
Example benchmark programs:


1. one one task with an infinite loop, no clock driver

2. one one task with an infinite loop, with clock driver

3. 2. +  create a second task

4. 3. + send/receive events

5. 3. + sem obtain/release

6. 3. + msg send/receive

7. 3. + barrier wait/release

...

Print sizeof(obj) for various objects.


--joel
___
devel mailing list
devel@rtems.org 
http://lists.rtems.org/mailman/listinfo/devel



--
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] STM32H7 doc update

[Robin Müller]

Hello,

Just another bump for the small doc patch and a reminder for another patch
I sent, which still needs some smaller adaptations for lwIP  ([PATCH] Basic
lwIP for STM32H7 BSP)
Kind Regards
Robin Müller

On Thu, 21 Jan 2021 at 13:52, Robin Müller 
wrote:

> I'd just like to bump my patch. The last changes were just the formatting
> changes from the code review.
>
>
> Kind Regards
> Robin
>
> On Tue, 12 Jan 2021 at 12:36, Robin Mueller 
> wrote:
>
>> ---
>>
>> Added doc for board variation, added some  fixes
>> from code review. (typo and line width formatting)
>>
>>  user/bsps/arm/stm32h7.rst | 18 +-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
>> index 3eee511..e1b9d8c 100644
>> --- a/user/bsps/arm/stm32h7.rst
>> +++ b/user/bsps/arm/stm32h7.rst
>> @@ -11,16 +11,32 @@ This BSP supports the
>>  The BSP is known to run on these boards:
>>
>>  * `STM32H743I-EVAL 2 <
>> https://www.st.com/en/evaluation-tools/stm32h743i-eval.html>`_
>> +* `STM32H743ZI-Nucleo <
>> https://www.st.com/en/evaluation-tools/nucleo-h743zi.html>`_
>>
>>  Clock Driver
>>  
>>
>> -The clock driver uses the `ARMv7-M Systick` module.
>> +The clock driver uses the `ARMv7-M Systick` module. The HSE (external
>> +oscillator) value can also be different for different evaluation or
>> custom
>> +boards, so it is recommended to check the default values of the BSP.
>>
>>  Console Driver
>>  --
>>
>>  The console driver supports the on-chip UART and USART modules.
>> +Different board variations use different GPIO pins and blocks for the
>> default
>> +communication UART and it is recommended to check whether the default
>> +configuration provided is valid in the BSP.
>> +
>> +To specify that the BSP should be built for the STM32H743ZI-Nucleo board,
>> +users can supply ``STM32H743ZI_NUCLEO == True`` to ``config.ini`` when
>> +building the BSP.
>> +
>> +Alternatively, users can supply the configuration structs defined in
>> ``hal.h``
>> +in the applicaton for other boards. For the console driver, the
>> +``stm32h7_usartX_config`` structs are used to configure the GPIO pins
>> and other
>> +parameters. The default implementations can be found in
>> +``bsps/arm/stm32ht/console`` in the RTEMS sources.
>>
>>  Network Interface Driver
>>  
>> --
>> 2.23.0.windows.1
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 12/12] c-user: Generate clock manager documentation

[Frank Kühndel]

Hello Sebastian,

On 2/10/21 5:28 PM, Sebastian Huber wrote:
> The documentation is a consolidation of the comments in Doxygen markup
> and the documentation sources in Sphinx markup.  The documentation was
> transfered to interface specification items.  The documentation source
> files were generated from the items by a script.
> 
> Update #3993.
> ---
>  c-user/clock/directives.rst   | 874 +++---
>  c-user/clock/introduction.rst |  83 +++-
>  c-user/glossary.rst   |  53 +++
>  3 files changed, 612 insertions(+), 398 deletions(-)
> 
> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
> index 06fe38b..55af03b 100644
> --- a/c-user/clock/directives.rst
> +++ b/c-user/clock/directives.rst
> @@ -1,549 +1,659 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> +.. Copyright (C) 2014, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
>  
> +.. This file is part of the RTEMS quality process and was automatically
> +.. generated.  If you find something that needs to be fixed or
> +.. worded better please post a report or patch to an RTEMS mailing list
> +.. or raise a bug report:
> +..
> +.. https://www.rtems.org/bugs.html
> +..
> +.. For information on updating and regenerating please refer to the How-To
> +.. section in the Software Requirements Engineering chapter of the
> +.. RTEMS Software Engineering manual.  The manual is provided as a part of
> +.. a release.  For development sources please refer to the online
> +.. documentation at:
> +..
> +.. https://docs.rtems.org
> +
> +.. _ClockManagerDirectives:
> +
>  Directives
>  ==
>  
> -This section details the clock manager's directives.  A subsection is 
> dedicated
> -to each of this manager's directives and describes the calling sequence,
> -related constants, usage, and status codes.
> +This section details the directives of the Clock Manager. A subsection is
> +dedicated to each of this manager's directives and lists the calling 
> sequence,
> +parameters, description, return values, and notes of the directive.
> +
> +.. Generated from spec:/rtems/clock/if/set
>  
>  .. raw:: latex
>  
> -   \clearpage
> +\clearpage
>  
> -.. index:: set the time of day
> -.. index:: rtems_clock_set
> +.. index:: rtems_clock_set()
>  
> -.. _rtems_clock_set:
> +.. _InterfaceRtemsClockSet:
>  
> -CLOCK_SET - Set date and time
> --
> +rtems_clock_set()
> +-
>  
> -CALLING SEQUENCE:
> -.. code-block:: c
> +Sets the :term:`CLOCK_REALTIME` to the time.
>  
> -rtems_status_code rtems_clock_set(
> -rtems_time_of_day *time_buffer
> -);
> +.. rubric:: CALLING SEQUENCE:
>  
> -DIRECTIVE STATUS CODES:
> -.. list-table::
> -  :class: rtems-table
> +.. code-block:: c
>  
> -  * - ``RTEMS_SUCCESSFUL``
> -- date and time set successfully
> -  * - ``RTEMS_INVALID_ADDRESS``
> -- ``time_buffer`` is NULL
> -  * - ``RTEMS_INVALID_CLOCK``
> -- invalid time of day
> +rtems_status_code rtems_clock_set( const rtems_time_of_day *time );

A comment only: The above is a change in the signature of the function
(adding `const`). Not that I object to it - on the contrary. Yet, it may
break existing code (e.g. code which uses function pointers to
rtems_clock_set() maybe). Not sure how the project deals with such
changes in the API.

Note: You renamed this parameter to `time` but you renamed the parameter
of rtems_clock_get_tod() to `time_of_day`.

>  
> -DESCRIPTION:
> -This directive sets the system date and time.  The date, time, and ticks 
> in
> -the time_buffer structure are all range-checked, and an error is returned
> -if any one is out of its valid range.
> +.. rubric:: PARAMETERS:
>  
> -NOTES:
> -Years before 1988 are invalid.
> +``time``
> +This parameter is the time to set the clock.
>  
> -The system date and time are based on the configured tick rate (number of
> -microseconds in a tick).
> +.. rubric:: RETURN VALUES:
>  
> -Setting the time forward may cause a higher priority task, blocked 
> waiting
> -on a specific time, to be made ready.  In this case, the calling task 
> will
> -be preempted after the next clock tick.
> +:c:macro:`RTEMS_SUCCESSFUL`
> +The requested operation was successful.
>  
> -Re-initializing RTEMS causes the system date and time to be reset to an
> -uninitialized state.  Another call to ``rtems_clock_set`` is required to
> -re-initialize the system date and time to application specific
> -specifications.
> +:c:macro:`RTEMS_INVALID_ADDRESS`
> +The ``time`` parameter was `NULL
> +`_.
>  
> -.. raw:: latex
> +:c:macro:`RTEMS_INVALID_CLOCK`
> +The time point specified by ``time`` was invalid.
>  
> -   \clearpage
> +.. rubric:: NOTES:
>  
> -.. index:: obtain the time of 

Re: Revisiting Minimum with Static Allocation

[Joel Sherrill]

On Thu, Feb 11, 2021 at 3:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 10/02/2021 21:36, Gedare Bloom wrote:
>
> >
> >
> > On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill  > > wrote:
> >
> > Hi
> >
> > The minimum sample is intended to show how to construct the
> > minimum footprint RTEMS application. I suspect that with
> > Sebastian's recent work on static allocation and reducing
> > footprint, the minimum sample may be able to benefit from tweaking.
> >
> > I just checked rtl22xx_t and it is < 16K code and 272 bytes of
> > data. :)
> >
> > Hello tends to be in the 64K range. Perhaps a static allocation
> > hello variant.
> >
> > Just wanting users to have good examples. A discussion at the
> > Flight Software Workshop mentioned RTEMS was big but it doesn't
> > seem to be if you look at executables which reflect those minimum
> > feature sets.
> >
> > Hoping Sebastian has magic settings to apply so these numbers are
> > as good as possible.
> >
> > This is a good idea. A "useful" minimum configuration with static
> > objects, or maybe even a couple of them, could be helpful to identify
> > reasonable bottom ends of the spectrum we can conceivably support.
>
> For the pre-qualification project we have to deliver some resource usage
> information. We would like to provide some benchmark programs and some
> rules to estimate the resource usage based on configuration options.
> Example benchmark programs:
>
> 1. one one task with an infinite loop, no clock driver
>
> 2. one one task with an infinite loop, with clock driver
>
> 3. 2. +  create a second task
>
> 4. 3. + send/receive events
>
> 5. 3. + sem obtain/release
>
> 6. 3. + msg send/receive
>
> 7. 3. + barrier wait/release
>

This is a good list but size measurement is always a pain. Architecture is
fixed for you but  ARM vs Thumb or SPARC vs their REX makes a big deal
and probably 2x since I think the erc32 minimum exe is ~28-32k where
rtl22xx_t is half that.

Using -Os can shrink things 10-12% based on history.

RTEMS options matter. Will the threads be statically constructed?
Will the init thread also be the idle thread?
SMP or uniprocessor?
Will you use the simple scheduler?
Or the default uniprocessor one?  Lower the maximum priorities?
Include a filesystem or not?

I recall one closed source RTEMS used to publish the size info that
didn't include the BSP. We could do this by "ld -r" against librtemscpu.a
and the application. At least reporting this size vs linked exe highlights
how some BSPs are just larger due to hardware complexity.

There is nothing wrong with what you listed. It is perfectly appropriate
for a qualification effort where many of the things I listed above are
held constant.

But I started this thread because I heard someone say RTEMS minimum
executable size was on the order of 100K where Zephyr was 10K. That is
likely comparing apples to oranges But I'd like to have some well
characterized cases that show we really do get down to that range. Yes
it would require cherry picking some of the parameters

+ Architecture: Thumb
+ GCC flags: -Os (maybe more)
+ RTEMS configuration: signals off? uniprocessor
+ What application?
- static init? Init as idle?
- Scheduler choice? Simple should be smaller.

When someone asks size of hello world (not on your list), the other
RTOS likely has console only output (printk) and not a robust POSIX
stack with stdio, termios, etc. Andt hen there is the choice of printf,
iprintf, or printk.

I think your list is great but I think we also need a true minimum
application that sets the bottom limit.


> ...
>
> Print sizeof(obj) for various objects.
>

This is spsize. Hopefully it can be updated/moved to meet their purposes.

Having a single directory of all these characterization tests is great. And
eventually having a larger set and corresponding documentation to explain
the delta between each one is important.

--joel


>
> > --joel
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
> --
> 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

Minimal Pi Support Library for Bare Metal

[Joel Sherrill]

Hi

https://github.com/jasLogic/mipea is a minimalistic peripheral access for
the Raspberry Pi under BSD-3 license. Not sure if it has anything that we
don't already but it may make a good reference in the future.

The README.md says it supports all variants and has been tested on a
variety of them.

Just noting it in the list so it is recorded. Looks potentially useful.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps/arm/imxrt: Add FDT and FDT helper for QTMR

[Christian Mauderer]

Makes it simpler to access the QTMR in an application via a FDT name or
link in an application specific FDT entry.
---
 bsps/arm/imxrt/include/fsl_qtmr.h | 34 
 bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi   | 24 +++
 .../nxp/devices/MIMXRT1052/drivers/fsl_qtmr.c | 40 +++
 3 files changed, 98 insertions(+)

diff --git a/bsps/arm/imxrt/include/fsl_qtmr.h 
b/bsps/arm/imxrt/include/fsl_qtmr.h
index 589b9c3597..a675413f8d 100644
--- a/bsps/arm/imxrt/include/fsl_qtmr.h
+++ b/bsps/arm/imxrt/include/fsl_qtmr.h
@@ -8,6 +8,9 @@
 #define _FSL_QTMR_H_
 
 #include "fsl_common.h"
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 /*!
  * @addtogroup qtmr
@@ -177,6 +180,37 @@ extern "C" {
  * @name Initialization and deinitialization
  * @{
  */
+#ifdef __rtems__
+/*!
+ * @brief Return the timer base based on a FDT node.
+ *
+ * @param fdt  Pointer to the fdt
+ * @param node The FDT node
+ *
+ * @return Pointer to the timer. NULL on error (for example if node isn't
+ * compatible).
+ */
+TMR_Type *QTMR_get_regs_from_fdt(const void *fdt, int node);
+
+/*!
+ * @brief Return the timer IRQ vector based on a FDT node.
+ *
+ * @param fdt  Pointer to the fdt
+ * @param node The FDT node
+ *
+ * @return IRQ vector number. BSP_INTERRUPT_VECTOR_INVALID on error.
+ */
+rtems_vector_number QTMR_get_IRQ_from_fdt(const void *fdt, int node);
+
+/*!
+ * @brief Return the clock source frequency of the quad timer.
+ *
+ * @param base Quad Timer peripheral base address.
+ *
+ * @return IRQ vector number. BSP_INTERRUPT_VECTOR_INVALID on error.
+ */
+uint32_t QTMR_get_src_clk(TMR_Type *base);
+#endif /* __rtems__ */
 
 /*!
  * @brief Ungates the Quad Timer clock and configures the peripheral for basic 
operation.
diff --git a/bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi 
b/bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
index 78c7b1c68e..610aa37e33 100644
--- a/bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
+++ b/bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
@@ -101,6 +101,30 @@
reg = <0x4010 0x0010>;
ranges;
 
+   qtimer4: timer@401e8000 {
+   compatible = "nxp,imxrt-qtimer";
+   reg = <0x401e8000 0x4000>;
+   interrupts = <136>;
+   };
+
+   qtimer3: timer@401e4000 {
+   compatible = "nxp,imxrt-qtimer";
+   reg = <0x401e4000 0x4000>;
+   interrupts = <135>;
+   };
+
+   qtimer2: timer@401e {
+   compatible = "nxp,imxrt-qtimer";
+   reg = <0x401e 0x4000>;
+   interrupts = <134>;
+   };
+
+   qtimer1: timer@401dc000 {
+   compatible = "nxp,imxrt-qtimer";
+   reg = <0x401dc000 0x4000>;
+   interrupts = <133>;
+   };
+
gpio4: gpio@401c4000 {
compatible = "fsl,imxrt-gpio",
"fsl,imx6ul-gpio", "fsl,imx35-gpio";
diff --git a/bsps/arm/imxrt/nxp/devices/MIMXRT1052/drivers/fsl_qtmr.c 
b/bsps/arm/imxrt/nxp/devices/MIMXRT1052/drivers/fsl_qtmr.c
index 44b7867441..f96e5504be 100644
--- a/bsps/arm/imxrt/nxp/devices/MIMXRT1052/drivers/fsl_qtmr.c
+++ b/bsps/arm/imxrt/nxp/devices/MIMXRT1052/drivers/fsl_qtmr.c
@@ -6,6 +6,11 @@
  */
 
 #include "fsl_qtmr.h"
+#ifdef __rtems__
+#include 
+#include 
+#include 
+#endif /* __rtems__ */
 
 /* Component ID definition, used by tools. */
 #ifndef FSL_COMPONENT_ID
@@ -56,6 +61,41 @@ static uint32_t QTMR_GetInstance(TMR_Type *base)
 return instance;
 }
 
+#ifdef __rtems__
+TMR_Type *QTMR_get_regs_from_fdt(const void *fdt, int node)
+{
+int rv;
+TMR_Type *regs;
+
+rv = fdt_node_check_compatible(fdt, node, "nxp,imxrt-qtimer");
+if (rv != 0) {
+return NULL;
+}
+regs = imx_get_reg_of_node(fdt, node);
+return regs;
+}
+
+rtems_vector_number QTMR_get_IRQ_from_fdt(const void *fdt, int node)
+{
+int rv;
+rtems_vector_number irq;
+
+rv = fdt_node_check_compatible(fdt, node, "nxp,imxrt-qtimer");
+if (rv != 0) {
+return BSP_INTERRUPT_VECTOR_INVALID;
+}
+irq = imx_get_irq_of_node(fdt, node, 0);
+return irq;
+}
+
+uint32_t QTMR_get_src_clk(TMR_Type *base)
+{
+(void) base;
+
+return CLOCK_GetFreq(kCLOCK_IpgClk);
+}
+
+#endif /* __rtems__ */
 /*!
  * brief Ungates the Quad Timer clock and configures the peripheral for basic 
operation.
  *
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/1] misc: tools: fix mkimage.py script type processing

[Jan Sommer]

Here is the patch from Andre also in git send-email format.
It would be great if we could integrate it in master and the 5 braches.

Best regards,

Jan

Andre Nahrwold (1):
  misc: tools: fix mkimage.py script type processing

 misc/tools/mkimage.py | 10 ++
 1 file changed, 10 insertions(+)

-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/1] misc: tools: fix mkimage.py script type processing

[Jan Sommer]

From: Andre Nahrwold 

---
 misc/tools/mkimage.py | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
index fd75f0a..111e224 100755
--- a/misc/tools/mkimage.py
+++ b/misc/tools/mkimage.py
@@ -121,6 +121,16 @@ outputfile.seek(struct.size);
 
 inputcrc = 0;
 
+if options.type in 'script':
+
+filler_struct = Struct("!II")
+inputblock = filler_struct.pack(inputsize, 0)
+
+inputcrc = binascii.crc32(inputblock, inputcrc)
+outputfile.write(inputblock)
+
+inputsize = inputsize + 8
+
 while True:
 inputblock = inputfile.read(4096)
 if not inputblock: break
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Question regarding RSB and open projects

[Ayushman Mishra]

Thank-you very much for help and clarification , I think i didn't
bootstrap the source code last time because this time I did get
configure file which i then used for make and make install , this time
I used enable-test=samples option and  while using rtems-test on erc32
, 11 test were performed.
And for the error pax is missing , I install pax separately , but
sadly again got Build error ( this time error report was very
confusing).

On Thu, Feb 11, 2021 at 12:40 AM Eshan Dhawan  wrote:
>
>
>
> On Thu, Feb 11, 2021 at 12:26 AM Ayushman Mishra  
> wrote:
>>
>> I tested the environment ./source-builder/sb-check , it gave this
>> result: RTEMS Source Builder - Check, 6 (61dcadee0825)
>> Environment is ok
>> When I used ../source-builder/sb-set-builder
>> --prefix=/home/ayush/quickstart1/rtems/6 --target=sparc-rtems6
>> --with-rtems-bsp=erc32 --with-rtems-tests=yes 6/rtems-sparc , it
>> started rebuilding and installing rtems-sparc tool suite ( just like
>> it did with this ../source-builder/sb-set-builder
>> --prefix=$HOME/quick-start/rtems/5 5/rtems-sparc , and took same
>> amount of time to complete the process) but no erc32 bsp was installed
>> ( bsp test said error: no executables supplied) , and using
>> 6/rtems-kernel instead of 6/rtems-sparc it gives same Build error (pax
>> is missing) , right now rsb is only working properly for rtems5 and
>> not rtems6 on my system.
>
> RSB builds the tools required to build rtems
> erc32 is a sparc BSP
> for building a BSP
> follow this : 
> https://docs.rtems.org/branches/master/user/installation/kernel.html
>>
>>
>> On Wed, Feb 10, 2021 at 11:44 AM Eshan Dhawan  
>> wrote:
>> >
>> >
>> >
>> > On Wed, Feb 10, 2021 at 10:36 AM Ayushman Mishra 
>> >  wrote:
>> >>
>> >> Thanks for the help Eshan but actually I have already performed this
>> >> step (sudo apt-get build-dep build-essential gcc-defaults g++ gdb git
>> >> \
>> >> unzip pax bison flex texinfo unzip python3-dev libpython-dev \
>> >> libncurses5-dev zlib1g-dev) , here since my system was not able to
>> >> find libpython-dev (Unable to find a source package for libpython-dev
>> >> ) so i used libpython2.7-dev , I tried with both python2-dev and 
>> >> python3-dev
>> >> (
>> >>  sudo apt-get build-dep build-essential gcc-defaults g++ gdb git \
>> >> unzip pax bison flex texinfo unzip python2-dev libpython2.7-dev \
>> >> libncurses5-dev zlib1g-dev
>> >> Reading package lists... Done
>> >> Picking 'gcc-defaults' as source package instead of 'g++'
>> >> Picking 'python-defaults' as source package instead of 'python2-dev'
>> >> Picking 'python2.7' as source package instead of 'libpython2.7-dev'
>> >> Picking 'ncurses' as source package instead of 'libncurses5-dev'
>> >> Picking 'zlib' as source package instead of 'zlib1g-dev'
>> >> Reading package lists... Done
>> >> Building dependency tree
>> >> Reading state information... Done
>> >> 0 upgraded, 0 newly installed, 0 to remove and 184 not upgraded.
>> >> ) ,
>> >
>> > did you test the environment
>> >
>> > ./source-builder/sb-check
>> >>
>> >> but then also same Build FAILED error comes up (configure: error: pax
>> >> is missing) . Also I wanted to know does the rsb in rtems6 uses
>> >> autoconf-based build system , since there is no configure file made
>> >> and used.
>> >
>> > Also, try using
>> >
>> > ../source-builder/sb-set-builder --prefix=/home/ayush/quickstart1/rtems/6 
>> > --target=sparc-rtems6 --with-rtems-bsp=erc32 --with-rtems-tests=yes 
>> > 6/rtems-sparc
>> >
>> >>
>> >> On Wed, Feb 10, 2021 at 1:04 AM Eshan Dhawan  
>> >> wrote:
>> >> >
>> >> > Hi ayushman
>> >> > It looks you didn't install all the dependencies required
>> >> > check this : 
>> >> > https://docs.rtems.org/branches/master/user/hosts/posix.html#linux
>> >> >
>> >> > On Wed, Feb 10, 2021 at 12:58 AM Ayushman Mishra 
>> >> >  wrote:
>> >> >>
>> >> >> Ayusman Mishra
>> >> >> 1. I was going through ticket #4145
>> >> >> (https://devel.rtems.org/ticket/4145) and tried building bsp on rtems6
>> >> >> and rtems5 both using rsb
>> >> >> (https://docs.rtems.org/branches/master/user/start/bsp-build.html#rsb-bsp-build)
>> >> >> but got Build FAILED (it says pax is missing (configure: error: pax is
>> >> >> missing.), I have attached full error report txt file). However I did
>> >> >> build bsp erc32 and pc386 using rsb on rtems5 (first .bootstrap -c
>> >> >> sb-bootstrap then used configure file
>> >> >> ($HOME/development/rtems/rtems-5/configure --target=i386-rtems5
>> >> >> --enable-rtemsbsp=pc386 )) on rtems6 there is no sb-bootstrap file or
>> >> >> configure file present/made.
>> >> >> I wanted to know is there anyway of using RSB on rtems6.
>> >> >> Also while building different bsp toolsets for rtems (erc32/pc386) I
>> >> >> used rtems on 2 different directories , Is there any way of building
>> >> >> different BSPs on same rtems?
>> >> >>
>> >> >> 2. I went through list of open projects and found projects related to
>> >> >> testing and development of ecosystem quite interesting,
>

Requests Patches to be Applied to 4.10

[Joel Sherrill]

Hi

Phillip Smith pinged me at the FSW via Slack about this set of patches he
proposed be added to the 4.10 branch.

https://lists.rtems.org/pipermail/devel/2019-April/025610.html

I assume this matches what their project requires. Given that 4.10 is the
last unirprocessor version and we appear to be recommending 5 over 4.11, I
suggest we consider applying the patches and discuss the possibility of
another release. [1]

I've previously suggested treating 4.10 as a long-term version since it is
the last uniprocessor version and a good baseline for behavior,
performance, and size.

[1] Yes I know release cutting is thankless unpaid work. First step is just
applying patches.

Thoughts?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requests Patches to be Applied to 4.10

[Gedare Bloom]

Hi Joel,

On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill  wrote:
>
> Hi
>
> Phillip Smith pinged me at the FSW via Slack about this set of patches he 
> proposed be added to the 4.10 branch.
>
> https://lists.rtems.org/pipermail/devel/2019-April/025610.html
>
> I assume this matches what their project requires. Given that 4.10 is the 
> last unirprocessor version and we appear to be recommending 5 over 4.11, I 
> suggest we consider applying the patches and discuss the possibility of 
> another release. [1]
>
> I've previously suggested treating 4.10 as a long-term version since it is 
> the last uniprocessor version and a good baseline for behavior, performance, 
> and size.
>
I've agreed with that view, and in fact we do have several (20+?)
patches that have been pushed on top of 4.10.2 (including some that
broke internal APIs such as my PIP improvements). So, these patches
can be considered for sure for a 4.10.3 cut. But we need to marshal
time and resources to make it happen. I'm willing to contribute as I
am able to do so.

> [1] Yes I know release cutting is thankless unpaid work. First step is just 
> applying patches.

If I remember the discussion right, we came to the conclusion that
maintaining 4.10 would require more resources than we have available
to commit. I would suggest we identify what the costs may be
(hardware, labor) for a long-term stable 4.10 version, and target some
fundraising toward users that would benefit from it. I guess there may
be at least some space and EPICS users that might be interested.

>
> Thoughts?
>
> --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: Requests Patches to be Applied to 4.10

[Joel Sherrill]

On Thu, Feb 11, 2021 at 1:47 PM Gedare Bloom  wrote:

> Hi Joel,
>
> On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill  wrote:
> >
> > Hi
> >
> > Phillip Smith pinged me at the FSW via Slack about this set of patches
> he proposed be added to the 4.10 branch.
> >
> > https://lists.rtems.org/pipermail/devel/2019-April/025610.html
> >
> > I assume this matches what their project requires. Given that 4.10 is
> the last unirprocessor version and we appear to be recommending 5 over
> 4.11, I suggest we consider applying the patches and discuss the
> possibility of another release. [1]
> >
> > I've previously suggested treating 4.10 as a long-term version since it
> is the last uniprocessor version and a good baseline for behavior,
> performance, and size.
> >
> I've agreed with that view, and in fact we do have several (20+?)
> patches that have been pushed on top of 4.10.2 (including some that
> broke internal APIs such as my PIP improvements). So, these patches
> can be considered for sure for a 4.10.3 cut. But we need to marshal
> time and resources to make it happen. I'm willing to contribute as I
> am able to do so.
>

I'm thinking initially just evaluate the patches Phillip's project used and
if they backport cleanly. If they don't, perhaps just file a ticket. If
they are
low hanging, just push them. And run tests on say leon3 and psim.


>
> > [1] Yes I know release cutting is thankless unpaid work. First step is
> just applying patches.
>
> If I remember the discussion right, we came to the conclusion that
> maintaining 4.10 would require more resources than we have available
> to commit. I would suggest we identify what the costs may be
> (hardware, labor) for a long-term stable 4.10 version, and target some
> fundraising toward users that would benefit from it. I guess there may
> be at least some space and EPICS users that might be interested.
>

Cutting a release does involve thankless work and fixing a patch which
doesn't backport very cleanly is also engineering.

I'm not disagreeing particularly on any point. We have finite resources
and funding core developers is the way to make something a priority.
I can definitively state that a user's sponsorship of a code developer
got the 5 series over the hump and 5.1 out the door. It was greatly
appreciated.

--joel


>
> >
> > Thoughts?
> >
> > --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

[PATCH 2/4] consolesimpletask.c: Fix Coverity Unchecked return value

[Ryan Long]

Fixes CID #1437625 and #1472765 where the return value of rtems_task_create and
rtems_task_start is discarded.
---
 cpukit/libcsupport/src/consolesimpletask.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/cpukit/libcsupport/src/consolesimpletask.c 
b/cpukit/libcsupport/src/consolesimpletask.c
index 82ea2a5..927085b 100644
--- a/cpukit/libcsupport/src/consolesimpletask.c
+++ b/cpukit/libcsupport/src/consolesimpletask.c
@@ -217,6 +217,7 @@ static const char _Console_simple_task_Name[] = "console";
 void _Console_simple_task_Initialize( void )
 {
   Console_simple_task_Control *cons;
+  rtems_status_code status;
 
   cons = &_Console_simple_task_Instance;
 
@@ -233,7 +234,7 @@ void _Console_simple_task_Initialize( void )
 
   IMFS_add_node( "/dev", &cons->Node, NULL );
 
-  rtems_task_create(
+  status = rtems_task_create(
 rtems_build_name('C', 'O', 'N', 'S'),
 RTEMS_MAXIMUM_PRIORITY - 1,
 RTEMS_MINIMUM_STACK_SIZE,
@@ -241,10 +242,12 @@ void _Console_simple_task_Initialize( void )
 RTEMS_DEFAULT_MODES,
 &cons->task
   );
+  _Assert_Unused_return_value_equal(status, RTEMS_SUCCESSFUL);
 
-  rtems_task_start(
+  status = rtems_task_start(
 cons->task,
 _Console_simple_task_Task,
 (rtems_task_argument) cons
   );
+  _Assert_Unused_return_value_equal(status, RTEMS_SUCCESSFUL);
 }
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/4] assert.h: Add macros to assert status and use it

[Ryan Long]

These macros are to be used to check the status from calls that are flagged by
Coverity as 'Unchecked return value'.
---
 cpukit/include/rtems/score/assert.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/cpukit/include/rtems/score/assert.h 
b/cpukit/include/rtems/score/assert.h
index cc32448..7efaae4 100644
--- a/cpukit/include/rtems/score/assert.h
+++ b/cpukit/include/rtems/score/assert.h
@@ -99,6 +99,36 @@ extern "C" {
 #endif
 
 /**
+ * @brief Assert if unused return value is equal.
+ *
+ * Assert whether @a _status and @a _value are equal and ensure @a _status is
+ * marked as used when not building for debug.
+ *
+ * @param _status The return value to be checked.
+ * @param _value Indicates what @a _status is supposed to be.
+ */
+#define _Assert_Unused_return_value_equal(_status,_value) \
+do { \
+  _Assert((_status) == (_value)); \
+  (void) (_status); \
+} while (0)
+
+/**
+ * @brief Assert if unused return value is not equal.
+ *
+ * Assert whether @a _status and @a _value are not equal and ensure @a _status
+ * is marked as used when not building for debug.
+ *
+ * @param _status The return value to be checked.
+ * @param _value Indicates what @a _status is not supposed to be.
+ */
+#define _Assert_Unused_return_value_not_equal(_status,_value) \
+ do { \
+  _Assert((_status) != (_value)); \
+   (void) (_status); \
+} while (0)
+
+/**
  * @brief Returns true if thread dispatching is allowed.
  *
  * Thread dispatching can be repressed via _Thread_Disable_dispatch() or
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/4] Fix for Coverity issues

[Ryan Long]

Hi,

I created some macros to assert the status returned from function calls,
and use that status based on Gedare and Joel's suggestions. I
implemented the macros in consolesimpletask.c. I fixed some issues for
the 'Dereference before null check' in a couple of files. This mainly
entailed moving around the dereferencing of values.

Thanks,
Ryan

Ryan Long (4):
  assert.h: Add macros to assert status and use it
  consolesimpletask.c: Fix Coverity Unchecked return value
  rtems-debugger-threads.c: Fix Coverity Dereference before null check
  rtems-debugger-target.c: Fix Coverity Dereference before null check

 cpukit/include/rtems/score/assert.h | 30 +
 cpukit/libcsupport/src/consolesimpletask.c  |  7 +--
 cpukit/libdebugger/rtems-debugger-target.c  |  5 +++--
 cpukit/libdebugger/rtems-debugger-threads.c | 14 +++---
 4 files changed, 49 insertions(+), 7 deletions(-)

-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Ryan Long]

Fixes CID #1468682 where target is dereferenced before it has been
checked as to whether it is null or not in the
rtems_debugger_target_swbreak_control function.
---
 cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index e495170..3726a6c 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -171,17 +171,18 @@ int
 rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT kind)
 {
   rtems_debugger_target* target = rtems_debugger->target;
-  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
   size_t swbreak_size;
   uint8_t*   loc = (void*) addr;
   size_t i;
   intr;
 
-  if (target == NULL || swbreaks == NULL || kind != target->breakpoint_size) {
+  if (target == NULL || target->swbreaks.block == NULL ||
+  kind != target->breakpoint_size) {
 errno = EIO;
 return -1;
   }
 
+  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
   swbreak_size =
 sizeof(rtems_debugger_target_swbreak) + target->breakpoint_size;
 
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 3/4] rtems-debugger-threads.c: Fix Coverity Dereference before null check

[Ryan Long]

Fixes CID #1468681, 1468690, and 1468694 by checking if threads is null in
the rtems_debugger_thread_find_index, rtems_debugger_thread_system_resume,
and rtems_debugger_thread_continue_all functions.
---
 cpukit/libdebugger/rtems-debugger-threads.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-threads.c 
b/cpukit/libdebugger/rtems-debugger-threads.c
index 84a9faa..5b96e5f 100644
--- a/cpukit/libdebugger/rtems-debugger-threads.c
+++ b/cpukit/libdebugger/rtems-debugger-threads.c
@@ -148,9 +148,9 @@ int
 rtems_debugger_thread_find_index(rtems_id id)
 {
   rtems_debugger_threads* threads = rtems_debugger->threads;
-  rtems_debugger_thread*  current = rtems_debugger_thread_current(threads);
   int r = -1;
   if (threads != NULL) {
+rtems_debugger_thread* current = rtems_debugger_thread_current(threads);
 size_t i;
 for (i = 0; i < threads->current.level; ++i) {
   if (id == 0 || current[i].id == id) {
@@ -347,8 +347,11 @@ rtems_debugger_thread_system_resume(bool detaching)
   rtems_debugger_threads* threads = rtems_debugger->threads;
   rtems_debugger_thread*  current;
   int r = 0;
+  if (threads == NULL) {
+return r;
+  }
   current = rtems_debugger_thread_current(threads);
-  if (threads != NULL && current != NULL) {
+  if (current != NULL) {
 size_t i;
 if (rtems_debugger_verbose())
   rtems_debugger_printf("rtems-db: sys:: resuming\n");
@@ -430,8 +433,13 @@ rtems_debugger_thread_continue_all(void)
   rtems_debugger_threads* threads = rtems_debugger->threads;
   rtems_debugger_thread*  current;
   int r = 0;
+  if (threads == NULL) {
+r = -1;
+errno = EIO;
+return r;
+  }
   current = rtems_debugger_thread_current(threads);
-  if (threads != NULL && current != NULL) {
+  if (current != NULL) {
 size_t i;
 for (i = 0; i < threads->current.level; ++i) {
   rtems_debugger_thread* thread = ¤t[i];
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 7:27 am, Ryan Long wrote:
> Fixes CID #1468682 where target is dereferenced before it has been
> checked as to whether it is null or not in the
> rtems_debugger_target_swbreak_control function.
> ---
>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
> b/cpukit/libdebugger/rtems-debugger-target.c
> index e495170..3726a6c 100644
> --- a/cpukit/libdebugger/rtems-debugger-target.c
> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> @@ -171,17 +171,18 @@ int
>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT 
> kind)
>  {
>rtems_debugger_target* target = rtems_debugger->target;
> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>size_t swbreak_size;
>uint8_t*   loc = (void*) addr;
>size_t i;
>intr;
>  
> -  if (target == NULL || swbreaks == NULL || kind != target->breakpoint_size) 
> {
> +  if (target == NULL || target->swbreaks.block == NULL ||
> +  kind != target->breakpoint_size) {
>  errno = EIO;
>  return -1;
>}
>  
> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;

The debug server does not declare local vars in the body of functions. I would
prefer the this code base stays that way if that is OK?

Chris

>swbreak_size =
>  sizeof(rtems_debugger_target_swbreak) + target->breakpoint_size;
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/4] rtems-debugger-threads.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 7:27 am, Ryan Long wrote:
> Fixes CID #1468681, 1468690, and 1468694 by checking if threads is null in
> the rtems_debugger_thread_find_index, rtems_debugger_thread_system_resume,
> and rtems_debugger_thread_continue_all functions.

Looks good. Thanks

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Joel Sherrill]

On Thu, Feb 11, 2021, 3:00 PM Chris Johns  wrote:

> On 12/2/21 7:27 am, Ryan Long wrote:
> > Fixes CID #1468682 where target is dereferenced before it has been
> > checked as to whether it is null or not in the
> > rtems_debugger_target_swbreak_control function.
> > ---
> >  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpukit/libdebugger/rtems-debugger-target.c
> b/cpukit/libdebugger/rtems-debugger-target.c
> > index e495170..3726a6c 100644
> > --- a/cpukit/libdebugger/rtems-debugger-target.c
> > +++ b/cpukit/libdebugger/rtems-debugger-target.c
> > @@ -171,17 +171,18 @@ int
> >  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr,
> DB_UINT kind)
> >  {
> >rtems_debugger_target* target = rtems_debugger->target;
> > -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >size_t swbreak_size;
> >uint8_t*   loc = (void*) addr;
> >size_t i;
> >intr;
> >
> > -  if (target == NULL || swbreaks == NULL || kind !=
> target->breakpoint_size) {
> > +  if (target == NULL || target->swbreaks.block == NULL ||
> > +  kind != target->breakpoint_size) {
> >  errno = EIO;
> >  return -1;
> >}
> >
> > +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>
> The debug server does not declare local vars in the body of functions. I
> would
> prefer the this code base stays that way if that is OK?
>

Then how do you want to address the issue identified by Coverity

>
> Chris
>
> >swbreak_size =
> >  sizeof(rtems_debugger_target_swbreak) + target->breakpoint_size;
> >
> >
> ___
> 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 1/4] assert.h: Add macros to assert status and use it

[Gedare Bloom]

On Thu, Feb 11, 2021 at 1:28 PM Ryan Long  wrote:
>
> These macros are to be used to check the status from calls that are flagged by
> Coverity as 'Unchecked return value'.
> ---
>  cpukit/include/rtems/score/assert.h | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/cpukit/include/rtems/score/assert.h 
> b/cpukit/include/rtems/score/assert.h
> index cc32448..7efaae4 100644
> --- a/cpukit/include/rtems/score/assert.h
> +++ b/cpukit/include/rtems/score/assert.h
> @@ -99,6 +99,36 @@ extern "C" {
>  #endif
>
>  /**
> + * @brief Assert if unused return value is equal.
Improve this phrase: "is equal to an expected status." maybe

> + *
> + * Assert whether @a _status and @a _value are equal and ensure @a _status is
s/whether/that

> + * marked as used when not building for debug.
> + *
> + * @param _status The return value to be checked.
> + * @param _value Indicates what @a _status is supposed to be.
> + */
> +#define _Assert_Unused_return_value_equal(_status,_value) \
I think "value_is_equal" will be better.

I think the name should be more clear that _status is a variable.
Maybe, _status_variable

Since a status can be a value. Or, call _status as _rv since it is
explicitly a returned value. It need not be a "status" indicator.

Similarily, instead of _value maybe it is better to call it
_check_value explicitly

> +do { \
> +  _Assert((_status) == (_value)); \
> +  (void) (_status); \
> +} while (0)
> +
> +/**
> + * @brief Assert if unused return value is not equal.

> + *
> + * Assert whether @a _status and @a _value are not equal and ensure @a 
> _status
> + * is marked as used when not building for debug.
> + *
> + * @param _status The return value to be checked.
> + * @param _value Indicates what @a _status is not supposed to be.
> + */
> +#define _Assert_Unused_return_value_not_equal(_status,_value) \
Maybe value_is_not

same as above, use _rv instead of _status

> + do { \
> +  _Assert((_status) != (_value)); \
> +   (void) (_status); \
> +} while (0)
> +
> +/**
>   * @brief Returns true if thread dispatching is allowed.
>   *
>   * Thread dispatching can be repressed via _Thread_Disable_dispatch() or
> --
> 1.8.3.1
>
> ___
> 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 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Gedare Bloom]

On Thu, Feb 11, 2021 at 1:28 PM Ryan Long  wrote:
>
> Fixes CID #1468682 where target is dereferenced before it has been
> checked as to whether it is null or not in the
> rtems_debugger_target_swbreak_control function.
> ---
>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
> b/cpukit/libdebugger/rtems-debugger-target.c
> index e495170..3726a6c 100644
> --- a/cpukit/libdebugger/rtems-debugger-target.c
> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> @@ -171,17 +171,18 @@ int
>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT 
> kind)
>  {
>rtems_debugger_target* target = rtems_debugger->target;
-  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
+  rtems_debugger_target_swbreak* swbreaks;

declare var here

>size_t swbreak_size;
>uint8_t*   loc = (void*) addr;
>size_t i;
>intr;
>
> -  if (target == NULL || swbreaks == NULL || kind != target->breakpoint_size) 
> {
> +  if (target == NULL || target->swbreaks.block == NULL ||
> +  kind != target->breakpoint_size) {
>  errno = EIO;
>  return -1;
>}
>
+  swbreaks = target->swbreaks.block;

use var here

>swbreak_size =
>  sizeof(rtems_debugger_target_swbreak) + target->breakpoint_size;
>
> --
> 1.8.3.1
>
> ___
> 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 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Gedare Bloom]

On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
>
> On 12/2/21 7:27 am, Ryan Long wrote:
> > Fixes CID #1468682 where target is dereferenced before it has been
> > checked as to whether it is null or not in the
> > rtems_debugger_target_swbreak_control function.
> > ---
> >  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
> > b/cpukit/libdebugger/rtems-debugger-target.c
> > index e495170..3726a6c 100644
> > --- a/cpukit/libdebugger/rtems-debugger-target.c
> > +++ b/cpukit/libdebugger/rtems-debugger-target.c
> > @@ -171,17 +171,18 @@ int
> >  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT 
> > kind)
> >  {
> >rtems_debugger_target* target = rtems_debugger->target;
> > -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >size_t swbreak_size;
> >uint8_t*   loc = (void*) addr;
> >size_t i;
> >intr;
> >
> > -  if (target == NULL || swbreaks == NULL || kind != 
> > target->breakpoint_size) {
> > +  if (target == NULL || target->swbreaks.block == NULL ||
> > +  kind != target->breakpoint_size) {
> >  errno = EIO;
> >  return -1;
> >}
> >
> > +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>
> The debug server does not declare local vars in the body of functions. I would
> prefer the this code base stays that way if that is OK?
>
Good catch. This is a holdover from ANSI C that we should generally
adhere to in RTEMS cpukit code for historical reasons.

> Chris
>
> >swbreak_size =
> >  sizeof(rtems_debugger_target_swbreak) + target->breakpoint_size;
> >
> >
> ___
> 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: Revisiting Minimum with Static Allocation

[Chris Johns]

On 12/2/21 1:17 am, Joel Sherrill wrote:
> 
> 
> On Thu, Feb 11, 2021 at 3:04 AM Sebastian Huber
>  >
> wrote:
> 
> On 10/02/2021 21:36, Gedare Bloom wrote:
> 
> >
> >
> > On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill  
> > >> wrote:
> >
> >     Hi
> >
> >     The minimum sample is intended to show how to construct the
> >     minimum footprint RTEMS application. I suspect that with
> >     Sebastian's recent work on static allocation and reducing
> >     footprint, the minimum sample may be able to benefit from tweaking.
> >
> >     I just checked rtl22xx_t and it is < 16K code and 272 bytes of
> >     data. :)
> >
> >     Hello tends to be in the 64K range. Perhaps a static allocation
> >     hello variant.
> >
> >     Just wanting users to have good examples. A discussion at the
> >     Flight Software Workshop mentioned RTEMS was big but it doesn't
> >     seem to be if you look at executables which reflect those minimum
> >     feature sets.
> >
> >     Hoping Sebastian has magic settings to apply so these numbers are
> >     as good as possible.
> >
> > This is a good idea. A "useful" minimum configuration with static
> > objects, or maybe even a couple of them, could be helpful to identify
> > reasonable bottom ends of the spectrum we can conceivably support.
> 
> For the pre-qualification project we have to deliver some resource usage
> information. We would like to provide some benchmark programs and some
> rules to estimate the resource usage based on configuration options.
> Example benchmark programs:
> 
> 1. one one task with an infinite loop, no clock driver
> 
> 2. one one task with an infinite loop, with clock driver
> 
> 3. 2. +  create a second task
> 
> 4. 3. + send/receive events
> 
> 5. 3. + sem obtain/release
> 
> 6. 3. + msg send/receive
> 
> 7. 3. + barrier wait/release
> 

Libc?

> 
> This is a good list but size measurement is always a pain. Architecture is 
> fixed for you but  ARM vs Thumb or SPARC vs their REX makes a big deal
> and probably 2x since I think the erc32 minimum exe is ~28-32k where
> rtl22xx_t is half that.
> 
> Using -Os can shrink things 10-12% based on history.
> 
> RTEMS options matter. Will the threads be statically constructed?
> Will the init thread also be the idle thread?
> SMP or uniprocessor?
> Will you use the simple scheduler? 
> Or the default uniprocessor one?  Lower the maximum priorities?
> Include a filesystem or not?
> 
> I recall one closed source RTEMS used to publish the size info that
> didn't include the BSP. We could do this by "ld -r" against librtemscpu.a
> and the application. At least reporting this size vs linked exe highlights 
> how some BSPs are just larger due to hardware complexity.
> 
> There is nothing wrong with what you listed. It is perfectly appropriate
> for a qualification effort where many of the things I listed above are
> held constant. 
> 
> But I started this thread because I heard someone say RTEMS minimum
> executable size was on the order of 100K where Zephyr was 10K. That is
> likely comparing apples to oranges But I'd like to have some well 
> characterized cases that show we really do get down to that range. Yes
> it would require cherry picking some of the parameters
> 
> + Architecture: Thumb
> + GCC flags: -Os (maybe more)
> + RTEMS configuration: signals off? uniprocessor
> + What application?
>     - static init? Init as idle?
>     - Scheduler choice? Simple should be smaller.
> 
> When someone asks size of hello world (not on your list), the other
> RTOS likely has console only output (printk) and not a robust POSIX
> stack with stdio, termios, etc. Andt hen there is the choice of printf,
> iprintf, or printk. 
> 
> I think your list is great but I think we also need a true minimum 
> application that sets the bottom limit.  
> 
> 
> ...
> 
> Print sizeof(obj) for various objects.
> 
> 
> This is spsize. Hopefully it can be updated/moved to meet their purposes. 
> 
> Having a single directory of all these characterization tests is great. And 
> eventually having a larger set and corresponding documentation to explain
> the delta between each one is important.

The rtems-exeinfo could display the size of object files without to much effort.
It has all the ELF data loaded.

What would be the key or keys ... text, data, const, all, a combination?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/4] assert.h: Add macros to assert status and use it

[Joel Sherrill]

On Thu, Feb 11, 2021 at 3:12 PM Gedare Bloom  wrote:

> On Thu, Feb 11, 2021 at 1:28 PM Ryan Long 
> wrote:
> >
> > These macros are to be used to check the status from calls that are
> flagged by
> > Coverity as 'Unchecked return value'.
> > ---
> >  cpukit/include/rtems/score/assert.h | 30 ++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/cpukit/include/rtems/score/assert.h
> b/cpukit/include/rtems/score/assert.h
> > index cc32448..7efaae4 100644
> > --- a/cpukit/include/rtems/score/assert.h
> > +++ b/cpukit/include/rtems/score/assert.h
> > @@ -99,6 +99,36 @@ extern "C" {
> >  #endif
> >
> >  /**
> > + * @brief Assert if unused return value is equal.
> Improve this phrase: "is equal to an expected status." maybe
>
> > + *
> > + * Assert whether @a _status and @a _value are equal and ensure @a
> _status is
> s/whether/that
>
> > + * marked as used when not building for debug.
> > + *
> > + * @param _status The return value to be checked.
> > + * @param _value Indicates what @a _status is supposed to be.
> > + */
> > +#define _Assert_Unused_return_value_equal(_status,_value) \
> I think "value_is_equal" will be better.
>
> I think the name should be more clear that _status is a variable.
> Maybe, _status_variable
>

When the name is long, it had a tendency to wrap. Got a shorter suggestion?

>
> Since a status can be a value. Or, call _status as _rv since it is
> explicitly a returned value. It need not be a "status" indicator.
>

And you do. _rv is fine with me. Ryan and I struggled to shorten names from
our initial discussion.


>
> Similarily, instead of _value maybe it is better to call it
> _check_value explicitly
>

Ryan try the longest names first. If it is > 80, try _rv and _expected.

>
> > +do { \
> > +  _Assert((_status) == (_value)); \
> > +  (void) (_status); \
> > +} while (0)
> > +
> > +/**
> > + * @brief Assert if unused return value is not equal.
>
> > + *
> > + * Assert whether @a _status and @a _value are not equal and ensure @a
> _status
> > + * is marked as used when not building for debug.
> > + *
> > + * @param _status The return value to be checked.
> > + * @param _value Indicates what @a _status is not supposed to be.
> > + */
> > +#define _Assert_Unused_return_value_not_equal(_status,_value) \
> Maybe value_is_not
>
> same as above, use _rv instead of _status
>
> > + do { \
> > +  _Assert((_status) != (_value)); \
> > +   (void) (_status); \
> > +} while (0)
> > +
> > +/**
> >   * @brief Returns true if thread dispatching is allowed.
> >   *
> >   * Thread dispatching can be repressed via _Thread_Disable_dispatch() or
> > --
> > 1.8.3.1
> >
> > ___
> > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 8:03 am, Joel Sherrill wrote:
> On Thu, Feb 11, 2021, 3:00 PM Chris Johns  > wrote:
> 
> On 12/2/21 7:27 am, Ryan Long wrote:
> > Fixes CID #1468682 where target is dereferenced before it has been
> > checked as to whether it is null or not in the
> > rtems_debugger_target_swbreak_control function.
> > ---
> >  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpukit/libdebugger/rtems-debugger-target.c
> b/cpukit/libdebugger/rtems-debugger-target.c
> > index e495170..3726a6c 100644
> > --- a/cpukit/libdebugger/rtems-debugger-target.c
> > +++ b/cpukit/libdebugger/rtems-debugger-target.c
> > @@ -171,17 +171,18 @@ int
> >  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, 
> DB_UINT
> kind)
> >  {
> >    rtems_debugger_target*         target = rtems_debugger->target;
> > -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;

rtems_debugger_target_swbreak* swbreaks;

> >    size_t                         swbreak_size;
> >    uint8_t*                       loc = (void*) addr;
> >    size_t                         i;
> >    int                            r;
> > 
> > -  if (target == NULL || swbreaks == NULL || kind !=
> target->breakpoint_size) {
> > +  if (target == NULL || target->swbreaks.block == NULL ||
> > +      kind != target->breakpoint_size) {
> >      errno = EIO;
> >      return -1;
> >    }
> > 
> > +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;

swbreaks = target->swbreaks.block;

> 
> The debug server does not declare local vars in the body of functions. I 
> would
> prefer the this code base stays that way if that is OK?
> 
> 
> Then how do you want to address the issue identified by Coverity
> 

As above. Like us old timers always did with C :) :).

As someone who likes and uses C++ I prefer C to clearly have the local vars at
the start of the block.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 8:16 am, Gedare Bloom wrote:
> On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
>>
>> On 12/2/21 7:27 am, Ryan Long wrote:
>>> Fixes CID #1468682 where target is dereferenced before it has been
>>> checked as to whether it is null or not in the
>>> rtems_debugger_target_swbreak_control function.
>>> ---
>>>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
>>> b/cpukit/libdebugger/rtems-debugger-target.c
>>> index e495170..3726a6c 100644
>>> --- a/cpukit/libdebugger/rtems-debugger-target.c
>>> +++ b/cpukit/libdebugger/rtems-debugger-target.c
>>> @@ -171,17 +171,18 @@ int
>>>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, DB_UINT 
>>> kind)
>>>  {
>>>rtems_debugger_target* target = rtems_debugger->target;
>>> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>>>size_t swbreak_size;
>>>uint8_t*   loc = (void*) addr;
>>>size_t i;
>>>intr;
>>>
>>> -  if (target == NULL || swbreaks == NULL || kind != 
>>> target->breakpoint_size) {
>>> +  if (target == NULL || target->swbreaks.block == NULL ||
>>> +  kind != target->breakpoint_size) {
>>>  errno = EIO;
>>>  return -1;
>>>}
>>>
>>> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>>
>> The debug server does not declare local vars in the body of functions. I 
>> would
>> prefer the this code base stays that way if that is OK?
>>
> Good catch. This is a holdover from ANSI C that we should generally
> adhere to in RTEMS cpukit code for historical reasons.

Yes I agree. I understand and accept this is a personal thing and I stated my
preference in the other post.

I use this feature judicially in C++ where I think it is more important to do
so. In C++ a variable can be declared in a number of ways and places and I feel
being consistent aids readability. Compilers are smart enough to figure out when
a variable become active and we do not need to help.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Joel Sherrill]

On Thu, Feb 11, 2021 at 3:29 PM Chris Johns  wrote:

> On 12/2/21 8:16 am, Gedare Bloom wrote:
> > On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
> >>
> >> On 12/2/21 7:27 am, Ryan Long wrote:
> >>> Fixes CID #1468682 where target is dereferenced before it has been
> >>> checked as to whether it is null or not in the
> >>> rtems_debugger_target_swbreak_control function.
> >>> ---
> >>>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/cpukit/libdebugger/rtems-debugger-target.c
> b/cpukit/libdebugger/rtems-debugger-target.c
> >>> index e495170..3726a6c 100644
> >>> --- a/cpukit/libdebugger/rtems-debugger-target.c
> >>> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> >>> @@ -171,17 +171,18 @@ int
> >>>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr,
> DB_UINT kind)
> >>>  {
> >>>rtems_debugger_target* target = rtems_debugger->target;
> >>> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >>>size_t swbreak_size;
> >>>uint8_t*   loc = (void*) addr;
> >>>size_t i;
> >>>intr;
> >>>
> >>> -  if (target == NULL || swbreaks == NULL || kind !=
> target->breakpoint_size) {
> >>> +  if (target == NULL || target->swbreaks.block == NULL ||
> >>> +  kind != target->breakpoint_size) {
> >>>  errno = EIO;
> >>>  return -1;
> >>>}
> >>>
> >>> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >>
> >> The debug server does not declare local vars in the body of functions.
> I would
> >> prefer the this code base stays that way if that is OK?
> >>
> > Good catch. This is a holdover from ANSI C that we should generally
> > adhere to in RTEMS cpukit code for historical reasons.
>
> Yes I agree. I understand and accept this is a personal thing and I stated
> my
> preference in the other post.
>

No. I missed that you wanted the variable at the top of scope. I agree that
tighter scoping is more a C++ thing than a C thing.  I was looking for
something
more complicated.

>
> I use this feature judicially in C++ where I think it is more important to
> do
> so. In C++ a variable can be declared in a number of ways and places and I
> feel
> being consistent aids readability. Compilers are smart enough to figure
> out when
> a variable become active and we do not need to help.
>

It is nice when a temporary variable is only used inside an if or loop.

--joel

>
> Chris
> ___
> 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 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Gedare Bloom]

On Thu, Feb 11, 2021 at 2:33 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Feb 11, 2021 at 3:29 PM Chris Johns  wrote:
>>
>> On 12/2/21 8:16 am, Gedare Bloom wrote:
>> > On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
>> >>
>> >> On 12/2/21 7:27 am, Ryan Long wrote:
>> >>> Fixes CID #1468682 where target is dereferenced before it has been
>> >>> checked as to whether it is null or not in the
>> >>> rtems_debugger_target_swbreak_control function.
>> >>> ---
>> >>>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
>> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
>> >>> b/cpukit/libdebugger/rtems-debugger-target.c
>> >>> index e495170..3726a6c 100644
>> >>> --- a/cpukit/libdebugger/rtems-debugger-target.c
>> >>> +++ b/cpukit/libdebugger/rtems-debugger-target.c
>> >>> @@ -171,17 +171,18 @@ int
>> >>>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, 
>> >>> DB_UINT kind)
>> >>>  {
>> >>>rtems_debugger_target* target = rtems_debugger->target;
>> >>> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>> >>>size_t swbreak_size;
>> >>>uint8_t*   loc = (void*) addr;
>> >>>size_t i;
>> >>>intr;
>> >>>
>> >>> -  if (target == NULL || swbreaks == NULL || kind != 
>> >>> target->breakpoint_size) {
>> >>> +  if (target == NULL || target->swbreaks.block == NULL ||
>> >>> +  kind != target->breakpoint_size) {
>> >>>  errno = EIO;
>> >>>  return -1;
>> >>>}
>> >>>
>> >>> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>> >>
>> >> The debug server does not declare local vars in the body of functions. I 
>> >> would
>> >> prefer the this code base stays that way if that is OK?
>> >>
>> > Good catch. This is a holdover from ANSI C that we should generally
>> > adhere to in RTEMS cpukit code for historical reasons.
>>
>> Yes I agree. I understand and accept this is a personal thing and I stated my
>> preference in the other post.
>
>
> No. I missed that you wanted the variable at the top of scope. I agree that
> tighter scoping is more a C++ thing than a C thing.  I was looking for 
> something
> more complicated.
>>
>>
>> I use this feature judicially in C++ where I think it is more important to do
>> so. In C++ a variable can be declared in a number of ways and places and I 
>> feel
>> being consistent aids readability. Compilers are smart enough to figure out 
>> when
>> a variable become active and we do not need to help.
>
>
> It is nice when a temporary variable is only used inside an if or loop.
>

It is naughty when a block variable shadows a different local variable
(or a global). So there are pros/cons, as usual.

> --joel
>>
>>
>> Chris
>> ___
>> 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 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 8:33 am, Joel Sherrill wrote:
> 
> 
> On Thu, Feb 11, 2021 at 3:29 PM Chris Johns  > wrote:
> 
> On 12/2/21 8:16 am, Gedare Bloom wrote:
> > On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  > wrote:
> >>
> >> On 12/2/21 7:27 am, Ryan Long wrote:
> >>> Fixes CID #1468682 where target is dereferenced before it has been
> >>> checked as to whether it is null or not in the
> >>> rtems_debugger_target_swbreak_control function.
> >>> ---
> >>>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/cpukit/libdebugger/rtems-debugger-target.c
> b/cpukit/libdebugger/rtems-debugger-target.c
> >>> index e495170..3726a6c 100644
> >>> --- a/cpukit/libdebugger/rtems-debugger-target.c
> >>> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> >>> @@ -171,17 +171,18 @@ int
> >>>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr,
> DB_UINT kind)
> >>>  {
> >>>    rtems_debugger_target*         target = rtems_debugger->target;
> >>> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >>>    size_t                         swbreak_size;
> >>>    uint8_t*                       loc = (void*) addr;
> >>>    size_t                         i;
> >>>    int                            r;
> >>>
> >>> -  if (target == NULL || swbreaks == NULL || kind !=
> target->breakpoint_size) {
> >>> +  if (target == NULL || target->swbreaks.block == NULL ||
> >>> +      kind != target->breakpoint_size) {
> >>>      errno = EIO;
> >>>      return -1;
> >>>    }
> >>>
> >>> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >>
> >> The debug server does not declare local vars in the body of functions. 
> I
> would
> >> prefer the this code base stays that way if that is OK?
> >>
> > Good catch. This is a holdover from ANSI C that we should generally
> > adhere to in RTEMS cpukit code for historical reasons.
> 
> Yes I agree. I understand and accept this is a personal thing and I 
> stated my
> preference in the other post.
> 
> 
> No. I missed that you wanted the variable at the top of scope. I agree that 
> tighter scoping is more a C++ thing than a C thing.  I was looking for 
> something
> more complicated.

Ah OK.

> I use this feature judicially in C++ where I think it is more important 
> to do
> so. In C++ a variable can be declared in a number of ways and places and 
> I feel
> being consistent aids readability. Compilers are smart enough to figure 
> out when
> a variable become active and we do not need to help.
> 
> 
> It is nice when a temporary variable is only used inside an if or loop. 

That is a block and fine. I am sorry if that was not clear. I fully support
doing this and think it is important to do.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Chris Johns]

On 12/2/21 8:35 am, Gedare Bloom wrote:
> On Thu, Feb 11, 2021 at 2:33 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Thu, Feb 11, 2021 at 3:29 PM Chris Johns  wrote:
>>>
>>> On 12/2/21 8:16 am, Gedare Bloom wrote:
 On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
>
> On 12/2/21 7:27 am, Ryan Long wrote:
>> Fixes CID #1468682 where target is dereferenced before it has been
>> checked as to whether it is null or not in the
>> rtems_debugger_target_swbreak_control function.
>> ---
>>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
>> b/cpukit/libdebugger/rtems-debugger-target.c
>> index e495170..3726a6c 100644
>> --- a/cpukit/libdebugger/rtems-debugger-target.c
>> +++ b/cpukit/libdebugger/rtems-debugger-target.c
>> @@ -171,17 +171,18 @@ int
>>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, 
>> DB_UINT kind)
>>  {
>>rtems_debugger_target* target = rtems_debugger->target;
>> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>>size_t swbreak_size;
>>uint8_t*   loc = (void*) addr;
>>size_t i;
>>intr;
>>
>> -  if (target == NULL || swbreaks == NULL || kind != 
>> target->breakpoint_size) {
>> +  if (target == NULL || target->swbreaks.block == NULL ||
>> +  kind != target->breakpoint_size) {
>>  errno = EIO;
>>  return -1;
>>}
>>
>> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
>
> The debug server does not declare local vars in the body of functions. I 
> would
> prefer the this code base stays that way if that is OK?
>
 Good catch. This is a holdover from ANSI C that we should generally
 adhere to in RTEMS cpukit code for historical reasons.
>>>
>>> Yes I agree. I understand and accept this is a personal thing and I stated 
>>> my
>>> preference in the other post.
>>
>>
>> No. I missed that you wanted the variable at the top of scope. I agree that
>> tighter scoping is more a C++ thing than a C thing.  I was looking for 
>> something
>> more complicated.
>>>
>>>
>>> I use this feature judicially in C++ where I think it is more important to 
>>> do
>>> so. In C++ a variable can be declared in a number of ways and places and I 
>>> feel
>>> being consistent aids readability. Compilers are smart enough to figure out 
>>> when
>>> a variable become active and we do not need to help.
>>
>>
>> It is nice when a temporary variable is only used inside an if or loop.
>>
> 
> It is naughty when a block variable shadows a different local variable
> (or a global). So there are pros/cons, as usual.

There is a warning for this. I thought it was on. Is it?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Remaining Waf Conversion Tickets for Community and GSoC Students

[Chris Johns]

On 11/2/21 7:50 pm, Sebastian Huber wrote:
> On 11/02/2021 00:20, Chris Johns wrote:
> 
>> On 10/2/21 4:20 pm, Sebastian Huber wrote:
>>> On 08/02/2021 10:40, Chris Johns wrote:
> It is written in Python 3.6.
 We still need to support python 2. Maybe having this file support both 
 could be
 part of the project.
>>> I think this BSP builder is a development tool which can use Python 3. It is
>>> useful to maintain RTEMS, but it is not a tool required for end users of 
>>> RTEMS
>>> to develop applications. Independent of this, the Python 2 end of life was a
>>> year ago.
>> This idea has real merit and it is pragmatic. Keeping rtems-central as 
>> python3
>> makes sense and it also makes sense to not pollute it with python2 code.
>>
>> Sebastian are you able to have rtems-central export the needed files to the
>> rtemstoolkit in rtems-tools?
>>
> One option is to simply copy
> 
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
> 
> to somewhere in rtems-tools. This module depends on the yaml module.

I am fine with adding the python YAML module to rtems-tools.

> Another option would be to use a special waf command (similar to 
> bsp_defaults),
> to output the information for the BSP builder in JSON format.

This could work but I am concerned wrapping this around waf may add a layer of
complexity. When it works it is fine but a wrapper in rtems-tools would also
need to handle all the regenerate message, waf general output, errors and
failure conditions? A tools needs to be robust with invalid data, ie some messed
up specs files. We would need to test a number of exec combinations such as
Windows, python 2, 3, virtual env, etc to make sure this works. It seems like a
lot of work.

Importing a python module of shared and common code seems simpler to me.

I under the subtle complexity around the time it takes to load the spec files
and the pickled data currently supportedf. I wonder how much faster a C or C++
YAML reader would be?

I see a number of tools we can add to help users interact with this new build
configuration data. Having a means to import and use this data seems important
to me.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/4] assert.h: Add macros to assert status and use it

[Gedare Bloom]

On Thu, Feb 11, 2021 at 2:19 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Feb 11, 2021 at 3:12 PM Gedare Bloom  wrote:
>>
>> On Thu, Feb 11, 2021 at 1:28 PM Ryan Long  wrote:
>> >
>> > These macros are to be used to check the status from calls that are 
>> > flagged by
>> > Coverity as 'Unchecked return value'.
>> > ---
>> >  cpukit/include/rtems/score/assert.h | 30 ++
>> >  1 file changed, 30 insertions(+)
>> >
>> > diff --git a/cpukit/include/rtems/score/assert.h 
>> > b/cpukit/include/rtems/score/assert.h
>> > index cc32448..7efaae4 100644
>> > --- a/cpukit/include/rtems/score/assert.h
>> > +++ b/cpukit/include/rtems/score/assert.h
>> > @@ -99,6 +99,36 @@ extern "C" {
>> >  #endif
>> >
>> >  /**
>> > + * @brief Assert if unused return value is equal.
>> Improve this phrase: "is equal to an expected status." maybe
>>
>> > + *
>> > + * Assert whether @a _status and @a _value are equal and ensure @a 
>> > _status is
>> s/whether/that
>>
>> > + * marked as used when not building for debug.
>> > + *
>> > + * @param _status The return value to be checked.
>> > + * @param _value Indicates what @a _status is supposed to be.
>> > + */
>> > +#define _Assert_Unused_return_value_equal(_status,_value) \
>> I think "value_is_equal" will be better.
>>
>> I think the name should be more clear that _status is a variable.
>> Maybe, _status_variable
>
>
> When the name is long, it had a tendency to wrap. Got a shorter suggestion?

_Assert_Unused_variable_equals(_var,_val)

>>
>>
>> Since a status can be a value. Or, call _status as _rv since it is
>> explicitly a returned value. It need not be a "status" indicator.
>
>
> And you do. _rv is fine with me. Ryan and I struggled to shorten names from
> our initial discussion.
>
>>
>>
>> Similarily, instead of _value maybe it is better to call it
>> _check_value explicitly
>
>
> Ryan try the longest names first. If it is > 80, try _rv and _expected.
>>
>>
>> > +do { \
>> > +  _Assert((_status) == (_value)); \
>> > +  (void) (_status); \
>> > +} while (0)
>> > +
>> > +/**
>> > + * @brief Assert if unused return value is not equal.
>>
>> > + *
>> > + * Assert whether @a _status and @a _value are not equal and ensure @a 
>> > _status
>> > + * is marked as used when not building for debug.
>> > + *
>> > + * @param _status The return value to be checked.
>> > + * @param _value Indicates what @a _status is not supposed to be.
>> > + */
>> > +#define _Assert_Unused_return_value_not_equal(_status,_value) \
>> Maybe value_is_not
>>
>> same as above, use _rv instead of _status

_Assert_Unused_variable_unequal():)

>>
>> > + do { \
>> > +  _Assert((_status) != (_value)); \
>> > +   (void) (_status); \
>> > +} while (0)
>> > +
>> > +/**
>> >   * @brief Returns true if thread dispatching is allowed.
>> >   *
>> >   * Thread dispatching can be repressed via _Thread_Disable_dispatch() or
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] rtems-debugger-target.c: Fix Coverity Dereference before null check

[Gedare Bloom]

On Thu, Feb 11, 2021 at 2:37 PM Chris Johns  wrote:
>
>
>
> On 12/2/21 8:35 am, Gedare Bloom wrote:
> > On Thu, Feb 11, 2021 at 2:33 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Thu, Feb 11, 2021 at 3:29 PM Chris Johns  wrote:
> >>>
> >>> On 12/2/21 8:16 am, Gedare Bloom wrote:
>  On Thu, Feb 11, 2021 at 2:00 PM Chris Johns  wrote:
> >
> > On 12/2/21 7:27 am, Ryan Long wrote:
> >> Fixes CID #1468682 where target is dereferenced before it has been
> >> checked as to whether it is null or not in the
> >> rtems_debugger_target_swbreak_control function.
> >> ---
> >>  cpukit/libdebugger/rtems-debugger-target.c | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
> >> b/cpukit/libdebugger/rtems-debugger-target.c
> >> index e495170..3726a6c 100644
> >> --- a/cpukit/libdebugger/rtems-debugger-target.c
> >> +++ b/cpukit/libdebugger/rtems-debugger-target.c
> >> @@ -171,17 +171,18 @@ int
> >>  rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr, 
> >> DB_UINT kind)
> >>  {
> >>rtems_debugger_target* target = rtems_debugger->target;
> >> -  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >>size_t swbreak_size;
> >>uint8_t*   loc = (void*) addr;
> >>size_t i;
> >>intr;
> >>
> >> -  if (target == NULL || swbreaks == NULL || kind != 
> >> target->breakpoint_size) {
> >> +  if (target == NULL || target->swbreaks.block == NULL ||
> >> +  kind != target->breakpoint_size) {
> >>  errno = EIO;
> >>  return -1;
> >>}
> >>
> >> +  rtems_debugger_target_swbreak* swbreaks = target->swbreaks.block;
> >
> > The debug server does not declare local vars in the body of functions. 
> > I would
> > prefer the this code base stays that way if that is OK?
> >
>  Good catch. This is a holdover from ANSI C that we should generally
>  adhere to in RTEMS cpukit code for historical reasons.
> >>>
> >>> Yes I agree. I understand and accept this is a personal thing and I 
> >>> stated my
> >>> preference in the other post.
> >>
> >>
> >> No. I missed that you wanted the variable at the top of scope. I agree that
> >> tighter scoping is more a C++ thing than a C thing.  I was looking for 
> >> something
> >> more complicated.
> >>>
> >>>
> >>> I use this feature judicially in C++ where I think it is more important 
> >>> to do
> >>> so. In C++ a variable can be declared in a number of ways and places and 
> >>> I feel
> >>> being consistent aids readability. Compilers are smart enough to figure 
> >>> out when
> >>> a variable become active and we do not need to help.
> >>
> >>
> >> It is nice when a temporary variable is only used inside an if or loop.
> >>
> >
> > It is naughty when a block variable shadows a different local variable
> > (or a global). So there are pros/cons, as usual.
>
> There is a warning for this. I thought it was on. Is it?
>
Probably. I'm just waxing philosophical. #bikeshed

> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel