[PATCH] Revert "test.h: Add pragma for gcc 12 warning"

2022-08-29 Thread Sebastian Huber 
This reverts commit 9e2289785b7a12684d96c72e219523e2810f0f10.

There is no issue with the T_flags_not_null() macro.  The uninitialized
use warnings must be fixed at the caller side of the macro.
---
 cpukit/include/rtems/test.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index e0823394d1..c283be7860 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -218,19 +218,12 @@ void T_check_null(const T_check_context_msg *, const void 
*);
 
 void T_check_not_null(const T_check_context_msg *, const void *);
 
-/*
- * This was added to address the following warning.
- * warning: 'a' may be used uninitialized
- */
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
 #define T_flags_not_null(a, flags, sa) \
 {  \
static const T_check_context_msg T_check_instance = {   \
{ T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT }, sa }; \
T_check_not_null(&T_check_instance, a); \
 }
-#pragma GCC diagnostic pop
 
 void T_check_eq_mem(const T_check_context_msg *, const void *, const void *,
 size_t);
-- 
2.35.3

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

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Sebastian Huber 

On 19/08/2022 22:46, Joel Sherrill wrote:

Module:rtems
Branch:master
Commit:5b875915152a248079855bcb98e871f70ac314cc
Changeset: 
http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc

Author:Ryan Long 
Date:  Tue Aug 16 12:00:26 2022 -0500

schedulerpriority.h: Fix gcc 12 warning

Changed the size of the array to 1 to get rid of the warning.

Updates #4662

---

  cpukit/include/rtems/score/schedulerpriority.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/schedulerpriority.h 
b/cpukit/include/rtems/score/schedulerpriority.h
index cf5d0762a9..e485e97c60 100644
--- a/cpukit/include/rtems/score/schedulerpriority.h
+++ b/cpukit/include/rtems/score/schedulerpriority.h
@@ -94,7 +94,7 @@ typedef struct {
/**
 * @brief One ready queue per priority level.
 */
-  Chain_Control Ready[ 0 ];
+  Chain_Control Ready[ 1 ];
  } Scheduler_priority_Context;


Increasing the storage size to fix a warning is the wrong approach.  The 
warning should be suppressed in the application configuration header or 
the configuration should be changed to account for the new chain control.


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

[PATCH] score: Do not expose to

2022-08-29 Thread Sebastian Huber 
Update #4662.
---
 cpukit/include/rtems/score/interr.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 0616220040..ae4966d6d8 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -38,8 +38,6 @@
 #ifndef _RTEMS_SCORE_INTERR_H
 #define _RTEMS_SCORE_INTERR_H
 
-#include 
-
 #include 
 
 /**
@@ -177,7 +175,7 @@ typedef enum {
* This enum value ensures that the enum type needs at least 32-bits for
* architectures with short enums.
*/
-  RTEMS_FATAL_SOURCE_LAST = INT_MAX
+  RTEMS_FATAL_SOURCE_LAST = 0x7fff
 } Internal_errors_Source;
 
 /**
-- 
2.35.3

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

Re: [PATCH] score: Do not expose to

2022-08-29 Thread Chris Johns 
Hi,

Welcome back :)

Could you please explain in the commit message the reason? It makes it easier
for me or anyone else to understand the reasons.

Thanks
Chris


On 29/8/22 5:11 pm, Sebastian Huber wrote:
> Update #4662.
> ---
>  cpukit/include/rtems/score/interr.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/cpukit/include/rtems/score/interr.h 
> b/cpukit/include/rtems/score/interr.h
> index 0616220040..ae4966d6d8 100644
> --- a/cpukit/include/rtems/score/interr.h
> +++ b/cpukit/include/rtems/score/interr.h
> @@ -38,8 +38,6 @@
>  #ifndef _RTEMS_SCORE_INTERR_H
>  #define _RTEMS_SCORE_INTERR_H
>  
> -#include 
> -
>  #include 
>  
>  /**
> @@ -177,7 +175,7 @@ typedef enum {
> * This enum value ensures that the enum type needs at least 32-bits for
> * architectures with short enums.
> */
> -  RTEMS_FATAL_SOURCE_LAST = INT_MAX
> +  RTEMS_FATAL_SOURCE_LAST = 0x7fff
>  } Internal_errors_Source;
>  
>  /**
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Chris Johns 
On 29/8/22 5:07 pm, Sebastian Huber wrote:
> On 19/08/2022 22:46, Joel Sherrill wrote:
>> Module:    rtems
>> Branch:    master
>> Commit:    5b875915152a248079855bcb98e871f70ac314cc
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc
>>
>> Author:    Ryan Long 
>> Date:  Tue Aug 16 12:00:26 2022 -0500
>>
>> schedulerpriority.h: Fix gcc 12 warning
>>
>> Changed the size of the array to 1 to get rid of the warning.
>>
>> Updates #4662
>>
>> ---
>>
>>   cpukit/include/rtems/score/schedulerpriority.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
>> b/cpukit/include/rtems/score/schedulerpriority.h
>> index cf5d0762a9..e485e97c60 100644
>> --- a/cpukit/include/rtems/score/schedulerpriority.h
>> +++ b/cpukit/include/rtems/score/schedulerpriority.h
>> @@ -94,7 +94,7 @@ typedef struct {
>>     /**
>>  * @brief One ready queue per priority level.
>>  */
>> -  Chain_Control Ready[ 0 ];
>> +  Chain_Control Ready[ 1 ];
>>   } Scheduler_priority_Context;
> 
> Increasing the storage size to fix a warning is the wrong approach.  The 
> warning
> should be suppressed in the application configuration header or the
> configuration should be changed to account for the new chain control.

Why do you say this is right or a better approach?

Chris

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

Re: qoriq build of rtems-libbsd

2022-08-29 Thread Sebastian Huber 

On 17/08/2022 23:01, Joel Sherrill wrote:

Sorry. Forgot to update my libbsd tree and got the wrong error. It is this:

/home/joel/rtems-work/tools/6/lib/gcc/powerpc-rtems6/12.1.1/../../../../powerpc-rtems6/bin/ld: 
./libbsd.a(nfs_clbio.c.10.o): the target (_bsd_unmapped_buf) of a 
R_PPC_SDAREL16 relocation is in the wrong output section (.data)

./libbsd.a(nfs_clbio.c.10.o): in function `ncl_putpages':
/home/joel/rtems-work/rtems-libbsd/build/powerpc-rtems6-qoriq_e6500_32-default/../../freebsd/sys/fs/nfsclient/nfs_clbio.c:349:(.text.ncl_putpages+0x22a): 
relocation truncated to fit: R_PPC_SDAREL16 against symbol 
`_bsd_unmapped_buf' defined in .data.read_mostly section in 
./libbsd.a(vfs_bio.c.20.o)

collect2: error: ld returned 1 exit status


I already fixed this in FreeBSD:

https://github.com/freebsd/freebsd-src/commit/ede6c6c0434a266a1712ffe807f4e31e229948df

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Sebastian Huber 

On 29/08/2022 09:30, Chris Johns wrote:

On 29/8/22 5:07 pm, Sebastian Huber wrote:

On 19/08/2022 22:46, Joel Sherrill wrote:

Module:    rtems
Branch:    master
Commit:    5b875915152a248079855bcb98e871f70ac314cc
Changeset:
http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc

Author:    Ryan Long
Date:  Tue Aug 16 12:00:26 2022 -0500

schedulerpriority.h: Fix gcc 12 warning

Changed the size of the array to 1 to get rid of the warning.

Updates #4662

---

   cpukit/include/rtems/score/schedulerpriority.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/schedulerpriority.h
b/cpukit/include/rtems/score/schedulerpriority.h
index cf5d0762a9..e485e97c60 100644
--- a/cpukit/include/rtems/score/schedulerpriority.h
+++ b/cpukit/include/rtems/score/schedulerpriority.h
@@ -94,7 +94,7 @@ typedef struct {
     /**
  * @brief One ready queue per priority level.
  */
-  Chain_Control Ready[ 0 ];
+  Chain_Control Ready[ 1 ];
   } Scheduler_priority_Context;

Increasing the storage size to fix a warning is the wrong approach.  The warning
should be suppressed in the application configuration header or the
configuration should be changed to account for the new chain control.

Why do you say this is right or a better approach?


A warning fix should not increase the storage size on the target. The 
Ready member is a flexible array those size is defined by the 
application configuration. This approach is used in several places. The 
declaration should be actually:


Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];

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

[PATCH v2] score: Do not expose to

2022-08-29 Thread Sebastian Huber 
The  header file should not unnecessarily include standard C
header files.  The  and  header includes were
removed in 2017.

Update #4662.
---
 cpukit/include/rtems/score/interr.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 0616220040..ae4966d6d8 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -38,8 +38,6 @@
 #ifndef _RTEMS_SCORE_INTERR_H
 #define _RTEMS_SCORE_INTERR_H
 
-#include 
-
 #include 
 
 /**
@@ -177,7 +175,7 @@ typedef enum {
* This enum value ensures that the enum type needs at least 32-bits for
* architectures with short enums.
*/
-  RTEMS_FATAL_SOURCE_LAST = INT_MAX
+  RTEMS_FATAL_SOURCE_LAST = 0x7fff
 } Internal_errors_Source;
 
 /**
-- 
2.35.3

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

Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

2022-08-29 Thread Sebastian Huber 

Hello Chris,

On 25/07/2022 08:12, Sebastian Huber wrote:

On 11/07/2022 15:04, Sebastian Huber wrote:

On 24/06/2022 08:33, Sebastian Huber wrote:
This patch set removes the FreeBSD file descriptors.  The VFS is no 
longer used

if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
application.  This change significantly reduce the memory usage of 
LibBSD for
these applications.  Using the media01 test case for the arm/lpc32xx 
BSP as a

benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" 
tasks are
no longer present in media01.  The code size is reduced by about 
8KiB.  The
data size is reduced by about 30KiB.  The throughput with a simple 
FTP test

increased by about 1%.

The "Remove FreeBSD file descriptors" change removes more lines than 
there are

added.

This change makes it easier to port the NFS support to the master 
branch since

now the changes are more localized.


I have a target with only 8MiB of RAM (for code and data). So, this 
patch set is not just a micro optimization.


This pending patch set is currently a blocker for me. I would like to 
work on the NTP daemon integration and an update of the libbsd master 
branch to a more recent FreeBSD version. This patch set just restores 
what worked well for several years.


did you have time to review this patch set in the meantime? The NTP 
client no longer crashes with this patch set.


--
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: qoriq build of rtems-libbsd

2022-08-29 Thread Joel Sherrill 
On Mon, Aug 29, 2022, 2:35 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 17/08/2022 23:01, Joel Sherrill wrote:
> > Sorry. Forgot to update my libbsd tree and got the wrong error. It is
> this:
> >
> >
> /home/joel/rtems-work/tools/6/lib/gcc/powerpc-rtems6/12.1.1/../../../../powerpc-rtems6/bin/ld:
>
> > ./libbsd.a(nfs_clbio.c.10.o): the target (_bsd_unmapped_buf) of a
> > R_PPC_SDAREL16 relocation is in the wrong output section (.data)
> > ./libbsd.a(nfs_clbio.c.10.o): in function `ncl_putpages':
> >
> /home/joel/rtems-work/rtems-libbsd/build/powerpc-rtems6-qoriq_e6500_32-default/../../freebsd/sys/fs/nfsclient/nfs_clbio.c:349:(.text.ncl_putpages+0x22a):
>
> > relocation truncated to fit: R_PPC_SDAREL16 against symbol
> > `_bsd_unmapped_buf' defined in .data.read_mostly section in
> > ./libbsd.a(vfs_bio.c.20.o)
> > collect2: error: ld returned 1 exit status
>
> I already fixed this in FreeBSD:
>
>
> https://github.com/freebsd/freebsd-src/commit/ede6c6c0434a266a1712ffe807f4e31e229948df


Is the fix in libbsd?

>
>
> --
> 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: qoriq build of rtems-libbsd

2022-08-29 Thread Sebastian Huber 

On 29/08/2022 13:55, Joel Sherrill wrote:



On Mon, Aug 29, 2022, 2:35 AM Sebastian Huber 
> wrote:


On 17/08/2022 23:01, Joel Sherrill wrote:
 > Sorry. Forgot to update my libbsd tree and got the wrong error.
It is this:
 >
 >

/home/joel/rtems-work/tools/6/lib/gcc/powerpc-rtems6/12.1.1/../../../../powerpc-rtems6/bin/ld:

 > ./libbsd.a(nfs_clbio.c.10.o): the target (_bsd_unmapped_buf) of a
 > R_PPC_SDAREL16 relocation is in the wrong output section (.data)
 > ./libbsd.a(nfs_clbio.c.10.o): in function `ncl_putpages':
 >

/home/joel/rtems-work/rtems-libbsd/build/powerpc-rtems6-qoriq_e6500_32-default/../../freebsd/sys/fs/nfsclient/nfs_clbio.c:349:(.text.ncl_putpages+0x22a):

 > relocation truncated to fit: R_PPC_SDAREL16 against symbol
 > `_bsd_unmapped_buf' defined in .data.read_mostly section in
 > ./libbsd.a(vfs_bio.c.20.o)
 > collect2: error: ld returned 1 exit status

I already fixed this in FreeBSD:


https://github.com/freebsd/freebsd-src/commit/ede6c6c0434a266a1712ffe807f4e31e229948df




Is the fix in libbsd?


No, not yet. My TODO list is a bit long 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

[PATCH rtems-lwip] lwipopts: Update for NTP

2022-08-29 Thread Kinsey Moore 
The default ZynqMP configuration is missing some definitions required
for NTP to function. This adjusts the default ZynqMP configuration to be
compatible with the NTP library's requirements.
---
 rtemslwip/zynqmp/lwipopts.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/rtemslwip/zynqmp/lwipopts.h b/rtemslwip/zynqmp/lwipopts.h
index 2d358a3..b9fe277 100644
--- a/rtemslwip/zynqmp/lwipopts.h
+++ b/rtemslwip/zynqmp/lwipopts.h
@@ -31,6 +31,7 @@
 
 #define NO_SYS 0
 #define LWIP_SOCKET 1
+#define SO_REUSE 1
 #define LWIP_COMPAT_SOCKETS 1
 #define LWIP_NETCONN 1
 
@@ -48,7 +49,8 @@
 #define MEM_ALIGNMENT   64
 #define MEM_SIZE2 * 1024 * 1024
 #define MEMP_NUM_PBUF   32
-#define MEMP_NUM_UDP_PCB4
+#define MEMP_NUM_NETCONN16
+#define MEMP_NUM_UDP_PCB16
 #define MEMP_NUM_TCP_PCB32
 #define MEMP_NUM_TCP_PCB_LISTEN 8
 #define MEMP_NUM_TCP_SEG256
@@ -114,6 +116,7 @@
 #define CONFIG_LINKSPEED_AUTODETECT 1
 #define TCPIP_MBOX_SIZE 20
 #define DEFAULT_TCP_RECVMBOX_SIZE   20
+#define DEFAULT_UDP_RECVMBOX_SIZE   20
 #define DEFAULT_ACCEPTMBOX_SIZE 5
 
 #define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY
-- 
2.30.2

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

[PATCH rtems-lwip] lwip.py: Address python formatting issues

2022-08-29 Thread Kinsey Moore 
---
 lwip.py | 106 
 1 file changed, 61 insertions(+), 45 deletions(-)

diff --git a/lwip.py b/lwip.py
index f8d8eb0..2e12957 100644
--- a/lwip.py
+++ b/lwip.py
@@ -29,43 +29,50 @@ from rtems_waf import rtems
 import json
 import os
 
+
 def removeprefix(data, prefix):
 if data.startswith(prefix):
 return data[len(prefix):]
 return data
 
+
+xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/'
+
 xilinx_drv_incl = ''
-xilinx_drv_incl += 
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/include '
-xilinx_drv_incl += './embeddedsw/lib/bsp/standalone/src/common '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
-xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
-xilinx_drv_incl += './rtemslwip/xilinx '
+xilinx_drv_incl += xilinx_lwip_prefix + 'src/contrib/ports/xilinx/include '
+xilinx_drv_incl += 'embeddedsw/lib/bsp/standalone/src/common '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
+xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
+xilinx_drv_incl += 'rtemslwip/xilinx '
 
 xilinx_aarch64_drv_incl = ''
-xilinx_aarch64_drv_incl += './rtemslwip/zynqmp '
-xilinx_aarch64_drv_incl += 
'./embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
-xilinx_aarch64_drv_incl += './embeddedsw/lib/bsp/standalone/src/arm/common/gcc 
'
-xilinx_aarch64_drv_incl += './embeddedsw/lib/bsp/standalone/src/arm/common '
+xilinx_aarch64_drv_incl += 'rtemslwip/zynqmp '
+xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
+xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common/gcc '
+xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common '
 
 # These sources are explicitly listed instead of using walk_sources below
 # because multiple BSPs of varying architecture are expected to use code from
 # the embeddedsw repository.
 xilinx_aarch64_driver_source = [
-
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c',
-
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xpqueue.c',
-
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
-
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
-'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
-'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
-'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
-'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
-'./embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xadapter.c',
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xpqueue.c',
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif.c',
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_dma.c',
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
+xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
+'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
+'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
+'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
+'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
+'embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
 ]
 
+
 def build(bld):
 source_files = []
-common_includes = './lwip/src/include ./uLan/ports/os/rtems 
./rtemslwip/include '
+common_includes = 'lwip/src/include uLan/ports/os/rtems rtemslwip/include '
 driver_source = []
 drv_incl = ' '
 bsd_compat_sources = [
@@ -73,7 +80,7 @@ def build(bld):
 "rtemslwip/bsd_compat/ifaddrs.c",
 "rtemslwip/bsd_compat/rtems-kernel-program.c"
 ]
-bsd_compat_incl = './rtemslwip/bsd_compat_include '
+bsd_compat_incl = 'rtemslwip/bsd_compat_include '
 
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
@@ -81,12 +88,12 @@ def build(bld):
 files = json.load(cf)
 for f in files['files-to-import']:
 if f[-2:] == '.c':
-source_files.append(os.path.join('./lwip', f))
+source_files.append(os.path.join('lwip', f))
 
-source_files.append('./uLan/ports/os/rtems/arch/sys_arch.c')
-source_files.append('./rtemslwip/common/syslog.c')
-source_files.append('./rtemslwip/common/rtems_lwip_io.c')
-source_files.append('./rtemslwip/common/network_compat.c')
+source_files.append('uLan/ports/os/rtems/arch/sys_arch

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Joel Sherrill 
On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/08/2022 09:30, Chris Johns wrote:
> > On 29/8/22 5:07 pm, Sebastian Huber wrote:
> >> On 19/08/2022 22:46, Joel Sherrill wrote:
> >>> Module:rtems
> >>> Branch:master
> >>> Commit:5b875915152a248079855bcb98e871f70ac314cc
> >>> Changeset:
> >>>
> http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc
> >>>
> >>> Author:Ryan Long
> >>> Date:  Tue Aug 16 12:00:26 2022 -0500
> >>>
> >>> schedulerpriority.h: Fix gcc 12 warning
> >>>
> >>> Changed the size of the array to 1 to get rid of the warning.
> >>>
> >>> Updates #4662
> >>>
> >>> ---
> >>>
> >>>cpukit/include/rtems/score/schedulerpriority.h | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
> >>> b/cpukit/include/rtems/score/schedulerpriority.h
> >>> index cf5d0762a9..e485e97c60 100644
> >>> --- a/cpukit/include/rtems/score/schedulerpriority.h
> >>> +++ b/cpukit/include/rtems/score/schedulerpriority.h
> >>> @@ -94,7 +94,7 @@ typedef struct {
> >>>  /**
> >>>   * @brief One ready queue per priority level.
> >>>   */
> >>> -  Chain_Control Ready[ 0 ];
> >>> +  Chain_Control Ready[ 1 ];
> >>>} Scheduler_priority_Context;
> >> Increasing the storage size to fix a warning is the wrong approach.
> The warning
> >> should be suppressed in the application configuration header or the
> >> configuration should be changed to account for the new chain control.
> > Why do you say this is right or a better approach?
>
> A warning fix should not increase the storage size on the target. The
> Ready member is a flexible array those size is defined by the
> application configuration. This approach is used in several places. The
> declaration should be actually:
>
> Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
>

The change to [1] was from a gcc documentation recommendation. Per
6.18 Arrays of Length Zero in the info installed with our GCC version, [0]
is a GNU extension and [1] is the C90 way to do it. We should not be using
a GNU extension.

In code which uses this construct (whether 0 or 1), if done in headers,
we can't assume users will compile with the array-bounds and/or
-Wzero-length-bounds disabled. If the warning is triggered in a header,
then it should be bracketed with the macros to disable the warning
temporarily.

--joel


> --
> 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 rtems-lwip] lwip.py: Address python formatting issues

2022-08-29 Thread Chris Johns 
On 30/8/2022 4:30 am, Kinsey Moore wrote:
> ---
>  lwip.py | 106 
>  1 file changed, 61 insertions(+), 45 deletions(-)
> 
> diff --git a/lwip.py b/lwip.py
> index f8d8eb0..2e12957 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -29,43 +29,50 @@ from rtems_waf import rtems
>  import json
>  import os
>  
> +
>  def removeprefix(data, prefix):
>  if data.startswith(prefix):
>  return data[len(prefix):]
>  return data
>  
> +
> +xilinx_lwip_prefix = 'embeddedsw/ThirdParty/sw_services/lwip211/'
> +
>  xilinx_drv_incl = ''
> -xilinx_drv_incl += 
> './embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/include 
> '
> -xilinx_drv_incl += './embeddedsw/lib/bsp/standalone/src/common '
> -xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
> -xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
> -xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
> -xilinx_drv_incl += './rtemslwip/xilinx '
> +xilinx_drv_incl += xilinx_lwip_prefix + 'src/contrib/ports/xilinx/include '
> +xilinx_drv_incl += 'embeddedsw/lib/bsp/standalone/src/common '
> +xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
> +xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
> +xilinx_drv_incl += 'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
> +xilinx_drv_incl += 'rtemslwip/xilinx '

Lists or strings? I prefer lists because weird paths can effect the waf
conversion from strings to lists.

This also goes for defines, fkags etc.

Otherwise looks good.

Thanks
Chris

>  
>  xilinx_aarch64_drv_incl = ''
> -xilinx_aarch64_drv_incl += './rtemslwip/zynqmp '
> -xilinx_aarch64_drv_incl += 
> './embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
> -xilinx_aarch64_drv_incl += 
> './embeddedsw/lib/bsp/standalone/src/arm/common/gcc '
> -xilinx_aarch64_drv_incl += './embeddedsw/lib/bsp/standalone/src/arm/common '
> +xilinx_aarch64_drv_incl += 'rtemslwip/zynqmp '
> +xilinx_aarch64_drv_incl += 
> 'embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
> +xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common/gcc 
> '
> +xilinx_aarch64_drv_incl += 'embeddedsw/lib/bsp/standalone/src/arm/common '
>  
>  # These sources are explicitly listed instead of using walk_sources below
>  # because multiple BSPs of varying architecture are expected to use code from
>  # the embeddedsw repository.
>  xilinx_aarch64_driver_source = [
> -
> './embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c',
> -
> './embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xpqueue.c',
> -
> './embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
> -
> './embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
> -'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
> -'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
> -'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
> -'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
> -'./embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
> +xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xadapter.c',
> +xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xpqueue.c',
> +xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif.c',
> +xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_dma.c',
> +xilinx_lwip_prefix + 'src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
> +xilinx_lwip_prefix + 
> 'src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
> +'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
> +'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
> +'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
> +'embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
> +'embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
>  ]
>  
> +
>  def build(bld):
>  source_files = []
> -common_includes = './lwip/src/include ./uLan/ports/os/rtems 
> ./rtemslwip/include '
> +common_includes = 'lwip/src/include uLan/ports/os/rtems 
> rtemslwip/include '
>  driver_source = []
>  drv_incl = ' '
>  bsd_compat_sources = [
> @@ -73,7 +80,7 @@ def build(bld):
>  "rtemslwip/bsd_compat/ifaddrs.c",
>  "rtemslwip/bsd_compat/rtems-kernel-program.c"
>  ]
> -bsd_compat_incl = './rtemslwip/bsd_compat_include '
> +bsd_compat_incl = 'rtemslwip/bsd_compat_include '
>  
>  arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>  bld.env.RTEMS_ARCH_BSP)
> @@ -81,12 +88,12 @@ def build(bld):
>  files = json.load(cf)
>  for f in files['files-to-import']:
>  if f[-2:] ==

Fwd: New Defects reported by Coverity Scan for RTEMS-Tools

2022-08-29 Thread Joel Sherrill 
I don't think this is due to a recent addition. I just upgraded to a new
version of the Coverity analysis tool.

Does anyone see a fix for this?

--joel
-- Forwarded message -
From: 
Date: Mon, Aug 29, 2022 at 5:14 PM
Subject: New Defects reported by Coverity Scan for RTEMS-Tools
To: 


Hi,

Please find the latest report on new defect(s) introduced to RTEMS-Tools
found with Coverity Scan.

11 new defect(s) introduced to RTEMS-Tools found with Coverity Scan.
7 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 11 of 11 defect(s)


** CID 1521908:  Memory - illegal accesses  (STRING_NULL)



*** CID 1521908:  Memory - illegal accesses  (STRING_NULL)
/rtemstoolkit/SimpleIni.h: 1377 in CSimpleIniTempl, SI_ConvertA>::LoadFile(_IO_FILE *)()
1371 if (uRead != (size_t) lSize) {
1372 delete[] pData;
1373 return SI_FILE;
1374 }
1375
1376 // convert the raw data to unicode
>>> CID 1521908:  Memory - illegal accesses  (STRING_NULL)
>>> Calling "LoadData" with the input string "pData", which is greater
than or equal to "uRead" in length, or not null-terminated.
1377 SI_Error rc = LoadData(pData, uRead);
1378 delete[] pData;
1379 return rc;
1380 }
1381
1382 template

** CID 1521907:  Memory - illegal accesses  (STRING_NULL)



*** CID 1521907:  Memory - illegal accesses  (STRING_NULL)
/rtemstoolkit/libiberty/cplus-dem.c: 2962 in demangle_prefix()
2956{
2957  /* No separator (I.E. "__not_mangled"), or empty
signature
2958 (I.E. "__not_mangled_either__") */
2959  success = 0;
2960}
2961  else
>>> CID 1521907:  Memory - illegal accesses  (STRING_NULL)
>>> Passing unterminated string "declp->b" to
"iterate_demangle_function", which expects a null-terminated string.
2962return iterate_demangle_function (work, mangled, declp,
scan);
2963}
2964 }
2965   else if (*(scan + 2) != '\0')
2966 {
2967   /* Mangled name does not start with "__" but does have one
somewhere

** CID 1521906:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
/rtemstoolkit/elftoolchain/libdwarf/libdwarf_rw.c: 418 in
_dwarf_decode_sleb128()



*** CID 1521906:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
/rtemstoolkit/elftoolchain/libdwarf/libdwarf_rw.c: 418 in
_dwarf_decode_sleb128()
412 int shift = 0;
413
414 uint8_t *src = *dp;
415
416 do {
417 b = *src++;
>>> CID 1521906:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
>>> Potentially overflowing expression "(b & 0x7f) << shift" with type
"int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type "int64_t" (64 bits, signed).
418 ret |= ((b & 0x7f) << shift);
419 shift += 7;
420 } while ((b & 0x80) != 0);
421
422 if (shift < 64 && (b & 0x40) != 0)
423 ret |= (-1 << shift);

** CID 1521905:  Insecure data handling  (TAINTED_SCALAR)



*** CID 1521905:  Insecure data handling  (TAINTED_SCALAR)
/rtemstoolkit/rld-elf.cpp: 574 in rld::elf::file::begin(const
std::basic_string, std::allocator>&,
int, bool, rld::elf::file*, long)()
568   writable = writable_;
569   elf_ = elf__;
570
571   if (!archive && !writable)
572   {
573 load_header ();
>>> CID 1521905:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted expression "this->ehdr" to "load_sections", which
uses it as a loop boundary.
574 load_sections ();
575   }
576 }
577
578 void
579 file::end ()

** CID 1521904:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
/rtemstoolkit/elftoolchain/libdwarf/libdwarf_rw.c: 423 in
_dwarf_decode_sleb128()



*** CID 1521904:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
/rtemstoolkit/elftoolchain/libdwarf/libdwarf_rw.c: 423 in
_dwarf_decode_sleb128()
417 b = *src++;
418 ret |= ((b & 0x7f) << shift);
419 shift += 7;
420 } while ((b & 0x80) != 0);
421
422 if (shift < 64 && (b & 0x40) != 0)
>>> CID 1521904:  Integer handling issues  (OV

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Chris Johns 
On 30/8/2022 6:39 am, Joel Sherrill wrote:
> On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber
>  >
> wrote:
> 
> On 29/08/2022 09:30, Chris Johns wrote:
> > On 29/8/22 5:07 pm, Sebastian Huber wrote:
> >> On 19/08/2022 22:46, Joel Sherrill wrote:
> >>> Module:    rtems
> >>> Branch:    master
> >>> Commit:    5b875915152a248079855bcb98e871f70ac314cc
> >>> Changeset:
> >>>
> 
> http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc
> 
> 
> >>>
> >>> Author:    Ryan Long >
> >>> Date:  Tue Aug 16 12:00:26 2022 -0500
> >>>
> >>> schedulerpriority.h: Fix gcc 12 warning
> >>>
> >>> Changed the size of the array to 1 to get rid of the warning.
> >>>
> >>> Updates #4662
> >>>
> >>> ---
> >>>
> >>>    cpukit/include/rtems/score/schedulerpriority.h | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
> >>> b/cpukit/include/rtems/score/schedulerpriority.h
> >>> index cf5d0762a9..e485e97c60 100644
> >>> --- a/cpukit/include/rtems/score/schedulerpriority.h
> >>> +++ b/cpukit/include/rtems/score/schedulerpriority.h
> >>> @@ -94,7 +94,7 @@ typedef struct {
> >>>      /**
> >>>   * @brief One ready queue per priority level.
> >>>   */
> >>> -  Chain_Control Ready[ 0 ];
> >>> +  Chain_Control Ready[ 1 ];
> >>>    } Scheduler_priority_Context;
> >> Increasing the storage size to fix a warning is the wrong approach.  
> The
> warning
> >> should be suppressed in the application configuration header or the
> >> configuration should be changed to account for the new chain control.
> > Why do you say this is right or a better approach?
> 
> A warning fix should not increase the storage size on the target. The
> Ready member is a flexible array those size is defined by the
> application configuration. This approach is used in several places. The
> declaration should be actually:
> 
> Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
> 
> 
> The change to [1] was from a gcc documentation recommendation. Per
> 6.18 Arrays of Length Zero in the info installed with our GCC version, [0]
> is a GNU extension and [1] is the C90 way to do it. We should not be using
> a GNU extension.
> 
> In code which uses this construct (whether 0 or 1), if done in headers, 
> we can't assume users will compile with the array-bounds and/or
> -Wzero-length-bounds disabled. If the warning is triggered in a header,
> then it should be bracketed with the macros to disable the warning
> temporarily.

I can see why the compiler does not like `[0]`. Why waste time and effort
managing a variable that has no size? It looks like a coding convenience the
compiler is now warning about. I see no point fighting the compiler.

Sebastian, where does making it 1 effect the code or target data size?

Do we have more cases of this that need to be considered?

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

Re: [PATCH v2] score: Do not expose to

2022-08-29 Thread Chris Johns 
Looks good and thanks

Is this in the coding standard?

Chris

On 29/8/2022 6:25 pm, Sebastian Huber wrote:
> The  header file should not unnecessarily include standard C
> header files.  The  and  header includes were
> removed in 2017.
> 
> Update #4662.
> ---
>  cpukit/include/rtems/score/interr.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/cpukit/include/rtems/score/interr.h 
> b/cpukit/include/rtems/score/interr.h
> index 0616220040..ae4966d6d8 100644
> --- a/cpukit/include/rtems/score/interr.h
> +++ b/cpukit/include/rtems/score/interr.h
> @@ -38,8 +38,6 @@
>  #ifndef _RTEMS_SCORE_INTERR_H
>  #define _RTEMS_SCORE_INTERR_H
>  
> -#include 
> -
>  #include 
>  
>  /**
> @@ -177,7 +175,7 @@ typedef enum {
> * This enum value ensures that the enum type needs at least 32-bits for
> * architectures with short enums.
> */
> -  RTEMS_FATAL_SOURCE_LAST = INT_MAX
> +  RTEMS_FATAL_SOURCE_LAST = 0x7fff
>  } Internal_errors_Source;
>  
>  /**
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: New Defects reported by Coverity Scan for RTEMS

2022-08-29 Thread Joel Sherrill 
Again..  issue lurking spotted by new version of Coverity Scan.

Please look at it and fix.

-- Forwarded message -
From: 
Date: Mon, Aug 29, 2022 at 5:55 PM
Subject: New Defects reported by Coverity Scan for RTEMS
To: 


Hi,

Please find the latest report on new defect(s) introduced to RTEMS found
with Coverity Scan.

61 new defect(s) introduced to RTEMS found with Coverity Scan.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 61 defect(s)


** CID 1512552:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()



*** CID 1512552:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
1798/* Go live with the new struct timehands. */
1799 #ifdef FFCLOCK
1800switch (sysclock_active) {
1801case SYSCLOCK_FBCK:
1802 #endif
1803time_second = th->th_microtime.tv_sec;
>>> CID 1512552:  High impact quality  (Y2K38_SAFETY)
>>> A "time_t" value is stored in an integer with too few bits to
accommodate it.  The expression "th->th_offset.sec" is cast to "int32_t".
1804time_uptime = th->th_offset.sec;
1805 #ifdef FFCLOCK
1806break;
1807case SYSCLOCK_FFWD:
1808time_second = fftimehands->tick_time_lerp.sec;
1809time_uptime = fftimehands->tick_time_lerp.sec -
ffclock_boottime.sec;

** CID 1512551:(Y2K38_SAFETY)
/bsps/shared/dev/getentropy/getentropy-cpucounter.c: 74 in getentropy_init()
/bsps/shared/dev/getentropy/getentropy-cpucounter.c: 75 in getentropy_init()



*** CID 1512551:(Y2K38_SAFETY)
/bsps/shared/dev/getentropy/getentropy-cpucounter.c: 74 in getentropy_init()
68 {
69   struct bintime bt;
70
71   rtems_bsd_bintime(&bt);
72   state = (uint32_t) bt.frac;
73   state ^= (uint32_t) (bt.frac >> 32);
>>> CID 1512551:(Y2K38_SAFETY)
>>> A "time_t" value is stored in an integer with too few bits to
accommodate it.  The expression "bt.sec" is cast to "uint32_t".
74   state ^= (uint32_t) bt.sec;
75   state ^= (uint32_t) (bt.sec >> 32);
76 }
77
78 RTEMS_SYSINIT_ITEM(
79   getentropy_init,
80   RTEMS_SYSINIT_DEVICE_DRIVERS,
81   RTEMS_SYSINIT_ORDER_LAST_BUT_5
/bsps/shared/dev/getentropy/getentropy-cpucounter.c: 75 in getentropy_init()
69   struct bintime bt;
70
71   rtems_bsd_bintime(&bt);
72   state = (uint32_t) bt.frac;
73   state ^= (uint32_t) (bt.frac >> 32);
74   state ^= (uint32_t) bt.sec;
>>> CID 1512551:(Y2K38_SAFETY)
>>> A "time_t" value is stored in an integer with too few bits to
accommodate it.  The expression "bt.sec >> 32" is cast to "uint32_t".
75   state ^= (uint32_t) (bt.sec >> 32);
76 }
77
78 RTEMS_SYSINIT_ITEM(
79   getentropy_init,
80   RTEMS_SYSINIT_DEVICE_DRIVERS,
81   RTEMS_SYSINIT_ORDER_LAST_BUT_5

** CID 1512550:  High impact quality  (Y2K38_SAFETY)
/cpukit/libfs/src/jffs2/src/gc.c: 878 in jffs2_garbage_collect_dirent()



*** CID 1512550:  High impact quality  (Y2K38_SAFETY)
/cpukit/libfs/src/jffs2/src/gc.c: 878 in jffs2_garbage_collect_dirent()
872 rd.pino = cpu_to_je32(f->inocache->ino);
873 rd.version = cpu_to_je32(++f->highest_version);
874 rd.ino = cpu_to_je32(fd->ino);
875 /* If the times on this inode were set by explicit utime()
they can be different,
876so refrain from splatting them. */
877 if (JFFS2_F_I_MTIME(f) == JFFS2_F_I_CTIME(f))
>>> CID 1512550:  High impact quality  (Y2K38_SAFETY)
>>> A "time_t" value is stored in an integer with too few bits to
accommodate it.  The expression "((struct _inode *)((uintptr_t)f -
72U))->i_mtime" is cast to "__u32".
878 rd.mctime = cpu_to_je32(JFFS2_F_I_MTIME(f));
879 else
880 rd.mctime = cpu_to_je32(0);
881 rd.type = fd->type;
882 rd.node_crc = cpu_to_je32(crc32(0, &rd, sizeof(rd)-8));
883 rd.name_crc = cpu_to_je32(crc32(0, fd->name, rd.nsize));

** CID 1512549:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 2384 in _Timecounter_Tick_simple()



*** CID 1512549:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 2384 in _Timecounter_Tick_simple()
2378 #else
2379atomic_store_rel_int(&th->th_generation, th->th_generation
+ 1);

Fwd: Coverity Scan: Analysis completed for RTEMS

2022-08-29 Thread Joel Sherrill 
Another report from the new version. :(

-- Forwarded message -
From: 
Date: Mon, Aug 29, 2022, 5:55 PM
Subject: Coverity Scan: Analysis completed for RTEMS
To: 



Your request for analysis of RTEMS has been completed successfully.
The results are available at
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ81HXwCHW32Mihy8bA1BUtQ-3D-3DUrsk_CTvEjVoKhyc6dLmJJo1u9AYIk8P8bcAbCPbBDYvYSXr2GrDWO2-2FGlgKt34WfgOJEeerckyPsDgFlT1sstsXtwd5kHGOjL73bzEALokVhT2oUfR5Kh5NJU-2B-2Fgx8rLixZ1uSqgaIwRqzgK19SpzmNm6kKelEj-2FkQmkAOobCtNOBQErfp6tiVa4t-2FmCoimkOzzB4WY9v6Cf3PnfO-2Bl91XAQz9FKfLuaoPmWAlj7ow1pSjo-3D

Build ID: 476526

Analysis Summary:
   New defects found: 61
   Defects eliminated: 5

If you have difficulty understanding any defects, email us at
scan-ad...@coverity.com,
or post your question to StackOverflow
at
https://u15810271.ct.sendgrid.net/ls/click?upn=CTPegkVN6peWFCMEieYYmPWIi1E4yUS9EoqKFcNAiqhRq8qmgeBE-2Bdt3uvFRAFXd-2FlwX83-2FVVdybfzIMOby0qA-3D-3Di2kI_CTvEjVoKhyc6dLmJJo1u9AYIk8P8bcAbCPbBDYvYSXr2GrDWO2-2FGlgKt34WfgOJEeerckyPsDgFlT1sstsXtwURLUTLGsHsrAK93sOR7xD6GGPhb9g8-2FJwupu-2BwOV6XTsVOocdxOx9E9sjAtY1AaunYQRKq6qadP2gNuGuvMH0a1E8BUuh7sv4EEQBNBCYNG6nMTsCqU8sWSPOSVUPYsI-2BUxf3ezqtwpGVDfbDKUs6A-3D
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Defects reported by Coverity Scan for RTEMS

2022-08-29 Thread Sebastian Huber 

On 30/08/2022 00:56, scan-ad...@coverity.com wrote:

** CID 1512552:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()



*** CID 1512552:  High impact quality  (Y2K38_SAFETY)
/cpukit/score/src/kern_tc.c: 1804 in _Timecounter_Windup()
1798/* Go live with the new struct timehands. */
1799 #ifdef FFCLOCK
1800switch (sysclock_active) {
1801case SYSCLOCK_FBCK:
1802 #endif
1803time_second = th->th_microtime.tv_sec;

 CID 1512552:  High impact quality  (Y2K38_SAFETY)
 A "time_t" value is stored in an integer with too few bits to accommodate it.  The expression 
"th->th_offset.sec" is cast to "int32_t".

1804time_uptime = th->th_offset.sec;
1805 #ifdef FFCLOCK
1806break;
1807case SYSCLOCK_FFWD:
1808time_second = fftimehands->tick_time_lerp.sec;
1809time_uptime = fftimehands->tick_time_lerp.sec - 
ffclock_boottime.sec;

** CID 1512551:(Y2K38_SAFETY)


This seems to be a new Coverity feature. The Newlib time_t definition is:

#if defined(_USE_LONG_TIME_T) || __LONG_MAX__ > 0x7fffL
#define _TIME_T_ long
#else
#define _TIME_T_ __int_least64_t
#endif
typedef _TIME_T___time_t;

Does Coverity use the Newlib header files? The _USE_LONG_TIME_T should 
be undefined for RTEMS.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] schedulerpriority.h: Fix gcc 12 warning

2022-08-29 Thread Sebastian Huber 

On 30/08/2022 00:24, Chris Johns wrote:

On 30/8/2022 6:39 am, Joel Sherrill wrote:

On Mon, Aug 29, 2022 at 2:41 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

 On 29/08/2022 09:30, Chris Johns wrote:
 > On 29/8/22 5:07 pm, Sebastian Huber wrote:
 >> On 19/08/2022 22:46, Joel Sherrill wrote:
 >>> Module:    rtems
 >>> Branch:    master
 >>> Commit:    5b875915152a248079855bcb98e871f70ac314cc
 >>> Changeset:
 >>>
 
http://git.rtems.org/rtems/commit/?id=5b875915152a248079855bcb98e871f70ac314cc
 

 >>>
 >>> Author:    Ryan Longmailto:ryan.l...@oarcorp.com>>
 >>> Date:  Tue Aug 16 12:00:26 2022 -0500
 >>>
 >>> schedulerpriority.h: Fix gcc 12 warning
 >>>
 >>> Changed the size of the array to 1 to get rid of the warning.
 >>>
 >>> Updates #4662
 >>>
 >>> ---
 >>>
 >>>    cpukit/include/rtems/score/schedulerpriority.h | 2 +-
 >>>    1 file changed, 1 insertion(+), 1 deletion(-)
 >>>
 >>> diff --git a/cpukit/include/rtems/score/schedulerpriority.h
 >>> b/cpukit/include/rtems/score/schedulerpriority.h
 >>> index cf5d0762a9..e485e97c60 100644
 >>> --- a/cpukit/include/rtems/score/schedulerpriority.h
 >>> +++ b/cpukit/include/rtems/score/schedulerpriority.h
 >>> @@ -94,7 +94,7 @@ typedef struct {
 >>>      /**
 >>>   * @brief One ready queue per priority level.
 >>>   */
 >>> -  Chain_Control Ready[ 0 ];
 >>> +  Chain_Control Ready[ 1 ];
 >>>    } Scheduler_priority_Context;
 >> Increasing the storage size to fix a warning is the wrong approach.  The
 warning
 >> should be suppressed in the application configuration header or the
 >> configuration should be changed to account for the new chain control.
 > Why do you say this is right or a better approach?

 A warning fix should not increase the storage size on the target. The
 Ready member is a flexible array those size is defined by the
 application configuration. This approach is used in several places. The
 declaration should be actually:

 Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];


The change to [1] was from a gcc documentation recommendation. Per
6.18 Arrays of Length Zero in the info installed with our GCC version, [0]
is a GNU extension and [1] is the C90 way to do it. We should not be using
a GNU extension.

In code which uses this construct (whether 0 or 1), if done in headers,
we can't assume users will compile with the array-bounds and/or
-Wzero-length-bounds disabled. If the warning is triggered in a header,
then it should be bracketed with the macros to disable the warning
temporarily.

I can see why the compiler does not like `[0]`. Why waste time and effort
managing a variable that has no size? It looks like a coding convenience the
compiler is now warning about. I see no point fighting the compiler.


The [0] was used sometimes in RTEMS for arrays with a flexible size. The 
[0] is a GNU extensions.


We introduced RTEMS_ZERO_LENGTH_ARRAY to work with flexible array 
members and not using this define for Scheduler_priority_Context was an 
oversight.




Sebastian, where does making it 1 effect the code or target data size?


The scheduler context is statically initialized using:

  #define RTEMS_SCHEDULER_PRIORITY( name, prio_count ) \
static struct { \
  Scheduler_priority_Context Base; \
  Chain_Control  Ready[ ( prio_count ) ]; \
} SCHEDULER_PRIORITY_CONTEXT_NAME( name )

The number of supported priority levels depends on the application 
configuration.


This approach uses another GNU extension if flexible array members are 
used in "Base", since in this case the flexible array member is not the 
last member of struct SCHEDULER_PRIORITY_CONTEXT_NAME( name ).




Do we have more cases of this that need to be considered?


Yes, basically everything which uses [0] in a structure definition or 
RTEMS_ZERO_LENGTH_ARRAY.


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

[PATCH] libtest: Fix warnings without a pragma

2022-08-29 Thread Sebastian Huber 
It seems that recent GCC versions expect that functions with "const type *"
parameter will read from the referenced location.

Update #4662.
---
 cpukit/include/rtems/test.h   | 23 ---
 cpukit/libtest/t-test-checks.c| 12 ++--
 testsuites/libtests/ttest01/test-checks.c | 10 +-
 3 files changed, 19 insertions(+), 26 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index e0823394d1..aa6b4f88b2 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -187,50 +187,43 @@ extern const T_check_context T_special;
 T_flags_true(flags, \
 (a) != (T_VA_ARGS_FIRST(__VA_ARGS__)) T_VA_ARGS_MORE(__VA_ARGS__))
 
-void T_check_eq_ptr(const T_check_context_msg *, const void *, const void *);
+void T_check_eq_ptr(const T_check_context_msg *, uintptr_t, uintptr_t);
 
 #define T_flags_eq_ptr(a, e, flags, sa, se)\
 {  \
static const T_check_context_msg T_check_instance = {   \
{ T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT },   \
sa " == " se }; \
-   T_check_eq_ptr(&T_check_instance, a, e);\
+   T_check_eq_ptr(&T_check_instance, (uintptr_t)a, (uintptr_t)e);  \
 }
 
-void T_check_ne_ptr(const T_check_context_msg *, const void *, const void *);
+void T_check_ne_ptr(const T_check_context_msg *, uintptr_t, uintptr_t);
 
 #define T_flags_ne_ptr(a, e, flags, sa, se)\
 {  \
static const T_check_context_msg T_check_instance = {   \
{ T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT },   \
sa " != " se }; \
-   T_check_ne_ptr(&T_check_instance, a, e);\
+   T_check_ne_ptr(&T_check_instance, (uintptr_t)a, (uintptr_t)e);  \
 }
 
-void T_check_null(const T_check_context_msg *, const void *);
+void T_check_null(const T_check_context_msg *, uintptr_t);
 
 #define T_flags_null(a, flags, sa) \
 {  \
static const T_check_context_msg T_check_instance = {   \
{ T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT }, sa }; \
-   T_check_null(&T_check_instance, a); \
+   T_check_null(&T_check_instance, (uintptr_t)a);  \
 }
 
-void T_check_not_null(const T_check_context_msg *, const void *);
+void T_check_not_null(const T_check_context_msg *, uintptr_t);
 
-/*
- * This was added to address the following warning.
- * warning: 'a' may be used uninitialized
- */
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
 #define T_flags_not_null(a, flags, sa) \
 {  \
static const T_check_context_msg T_check_instance = {   \
{ T_FILE_NAME, __LINE__, (flags) | T_CHECK_FMT }, sa }; \
-   T_check_not_null(&T_check_instance, a); \
+   T_check_not_null(&T_check_instance, (uintptr_t)a);  \
 }
-#pragma GCC diagnostic pop
 
 void T_check_eq_mem(const T_check_context_msg *, const void *, const void *,
 size_t);
diff --git a/cpukit/libtest/t-test-checks.c b/cpukit/libtest/t-test-checks.c
index c86596521b..1a278b55ec 100644
--- a/cpukit/libtest/t-test-checks.c
+++ b/cpukit/libtest/t-test-checks.c
@@ -30,27 +30,27 @@
 #include 
 
 void
-T_check_eq_ptr(const T_check_context_msg *t, const void *a, const void *e)
+T_check_eq_ptr(const T_check_context_msg *t, uintptr_t a, uintptr_t e)
 {
T_check(&t->base, a == e, "%s", t->msg);
 }
 
 void
-T_check_ne_ptr(const T_check_context_msg *t, const void *a, const void *e)
+T_check_ne_ptr(const T_check_context_msg *t, uintptr_t a, uintptr_t e)
 {
T_check(&t->base, a != e, "%s", t->msg);
 }
 
 void
-T_check_null(const T_check_context_msg *t, const void *a)
+T_check_null(const T_check_context_msg *t, uintptr_t a)
 {
-   T_check(&t->base, a == NULL, "%s == NULL", t->msg);
+   T_check(&t->base, a == 0, "%s == NULL", t->msg);
 }
 
 void
-T_check_not_null(const T_check_context_msg *t, const void *a)
+T_check_not_null(const T_check_context_msg *t, uintptr_t a)
 {
-   T_check(&t->base, a != NULL, "%s != NULL", t->msg);
+   T_check(&t->base, a != 0, "%s != NULL", t->msg);
 }
 
 void
diff --git a/testsuites/libtests/ttest01/test-checks.c 
b/testsuites/libtests/ttest01/test-checks.c
index 06e1a959bf..fa5591121e 100644
--- a/testsuites/libtests/ttest01/test-checks.c
+++ b/testsuites/libtests/ttest01/test-checks.c
@@ -90,8 +90,8 @@ T_TEST_CASE(step_assert_eq_ptr)
 
 T_TEST_CASE(chec

[PATCH] Fix pedanic warnings without a storage increase

2022-08-29 Thread Sebastian Huber 
Use RTEMS_ZERO_LENGTH_ARRAY for flexible array member.

Update #4662.
---
 cpukit/include/rtems/confdefs/scheduler.h  | 10 ++
 cpukit/include/rtems/score/schedulerpriority.h |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/confdefs/scheduler.h 
b/cpukit/include/rtems/confdefs/scheduler.h
index 84ca810fd7..8ac943921f 100644
--- a/cpukit/include/rtems/confdefs/scheduler.h
+++ b/cpukit/include/rtems/confdefs/scheduler.h
@@ -234,7 +234,17 @@ extern "C" {
 #endif
 
 #ifdef CONFIGURE_SCHEDULER
+  /*
+   * Ignore these warnings:
+   *
+   * - invalid use of structure with flexible array member
+   *
+   * - struct has no members
+   */
+  #pragma GCC diagnostic push
+  #pragma GCC diagnostic ignored "-Wpedantic"
   CONFIGURE_SCHEDULER;
+  #pragma GCC diagnostic pop
 #endif
 
 const Scheduler_Control _Scheduler_Table[] = {
diff --git a/cpukit/include/rtems/score/schedulerpriority.h 
b/cpukit/include/rtems/score/schedulerpriority.h
index e485e97c60..1325224fa9 100644
--- a/cpukit/include/rtems/score/schedulerpriority.h
+++ b/cpukit/include/rtems/score/schedulerpriority.h
@@ -94,7 +94,7 @@ typedef struct {
   /**
* @brief One ready queue per priority level.
*/
-  Chain_Control Ready[ 1 ];
+  Chain_Control Ready[ RTEMS_ZERO_LENGTH_ARRAY ];
 } Scheduler_priority_Context;
 
 /**
-- 
2.35.3

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

[PATCH] validation: Ignore array bounds warnings

2022-08-29 Thread Sebastian Huber 
Update #4702.
---
 testsuites/validation/tc-intr-get-affinity.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/testsuites/validation/tc-intr-get-affinity.c 
b/testsuites/validation/tc-intr-get-affinity.c
index 277cb790a3..81f8da8ce2 100644
--- a/testsuites/validation/tc-intr-get-affinity.c
+++ b/testsuites/validation/tc-intr-get-affinity.c
@@ -244,6 +244,9 @@ static void CheckGetAffinity(
   rtems_status_code sc;
   cpu_set_t set[ 2 ];
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+
   if ( attr->can_get_affinity ) {
 CPU_ZERO_S( sizeof( ctx->cpuset_obj ), ctx->cpuset_obj );
   } else {
@@ -265,6 +268,8 @@ static void CheckGetAffinity(
 T_rsc( sc, RTEMS_UNSATISFIED );
 T_true( CPU_EQUAL_S( sizeof( set ), ctx->cpuset_obj, set ) );
   }
+
+#pragma GCC diagnostic pop
 }
 
 static void RtemsIntrReqGetAffinity_Pre_Vector_Prepare(
@@ -565,6 +570,9 @@ static void RtemsIntrReqGetAffinity_Action(
   ctx->vector = BSP_INTERRUPT_VECTOR_COUNT;
 }
 
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+
 CPU_FILL_S( sizeof( ctx->cpuset_obj ), ctx->cpuset_obj );
 
 ctx->status = rtems_interrupt_get_affinity(
@@ -583,6 +591,8 @@ static void RtemsIntrReqGetAffinity_Action(
 }
 
 T_true( CPU_EQUAL_S( sizeof( set ), ctx->cpuset_obj, set ) );
+
+#pragma GCC diagnostic pop
   }
 }
 
-- 
2.35.3

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