Warnings when building sparc/leon3

[Sebastian Huber]

On 08/03/2022 15:40, Joel Sherrill wrote:
> 
> On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>     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>
>      > <mailto: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>>
>      >      > <mailto: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>>
>      >      >     <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.
> 
> 
> The original behavior can't be re-implemented. When you made changes
> so there was always an MPCI Table, it fundamentally broke the assumption
> that one might not be present when MP is enabled.

We could change rtems_configuration_get_user_multiprocessing_table() to 
return NULL if CONFIGURE_MP_APPLICATION is not defined.

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