Warnings when building sparc/leon3

[Sebastian Huber]

On 08/03/2022 15:23, Joel Sherrill wrote:
> 
> 
> On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>     On 07/03/2022 19:19, Joel Sherrill wrote:
>      >
>      >
>      > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
>      > <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>      > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>      >
>      >     On 07/03/2022 17:48, Joel Sherrill wrote:
>      >      > This appears to be because
>      >      > rtems_configuration_get_user_multiprocessing_table()
>     always returns a
>      >      > non-NULL value when RTEMS_MULTIPROCESSING is defined. This
>     must
>      >     be a change
>      >      > versus previous behavior.
>      >      >
>      >      > Ryan and I noticed that the specific cases cited here
>     appeared to be
>      >      > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't need to worry
>      >     about it.
>      >      > But something has changed that impacts public facing behavior.
>      >
>      >     I think this is the related ticket:
>      >
>      > https://devel.rtems.org/ticket/3735
>     <https://devel.rtems.org/ticket/3735>
>      >     <https://devel.rtems.org/ticket/3735
>     <https://devel.rtems.org/ticket/3735>>
>      >
>      >
>      > OK. But apparently this was used to tell the difference between a
>      > single node system in MP configuration and a node within an
>      > MP configuration.  My grep shows some uses are really dereferencing
>      > the table but others like the one in amba.h:153 to define the clock
>      > index looks wrong. THere is similar code in leon.h:
>      >
>      > #if defined(RTEMS_MULTIPROCESSING)
>      >    #define LEON3_CLOCK_INDEX \
>      >     (rtems_configuration_get_user_multiprocessing_table() ?
>      > LEON3_Cpu_Index : 0)
> 
> 
>      > #else
>      >    #define LEON3_CLOCK_INDEX 0
>      > #endif
>      >
>      > That's the type of pattern that needs addressing. That test is
>      > asking in multiprocessing is configured in the application not
>      > in the build.
> 
>     The rtems_configuration_get_user_multiprocessing_table() ? X : Y
>     expressions can be simplified to X.
> 
> 
> That does not preserve the semantics of the original. In the original
> implementation, it could return NULL for an application configured
> to be a single processor with no distributed multiprocessing in use.
> 
> The change gets rid of the warning but doesn't 'retain the intent.

If you think the original behaviour of 
rtems_configuration_get_user_multiprocessing_table() is important, then 
it should be documented and tested.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at 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/