Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber <
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>> 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.
>

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.

I don't want it reverted. I wish all the cases where it was checking for
NULL
that broke when it could no longer be NULL were addressed at the time.
There had to be warnings if that configuration had been built.

We need to fix the use cases to align with the new behavior.  You fixed
some in Leon3 and Ryan has a patch for some in cpukit.

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