Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 8:46 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

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

That's how it is now.

#if defined(RTEMS_MULTIPROCESSING)
  #define rtems_configuration_get_user_multiprocessing_table() \
    ( &_MPCI_Configuration )
#else
  #define rtems_configuration_get_user_multiprocessing_table() NULL
#endif

I think all the use cases Ryan and I saw were protected by ifdef
RTEMS_MULTIPROCESSING. Perhaps this just should not be defined
if it isn't configured.

--joel

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