Workspace Initialization Faliure Bug

[Joel Sherrill]

On Fri, Oct 1, 2021, 12:10 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 01/10/2021 16:27, Joel Sherrill wrote:
> >
> >
> > On Fri, Oct 1, 2021, 8:42 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >
> >     On 01/10/2021 00:38, Joel Sherrill wrote:
> >      > I think in this configuration, the workspace is essentially
> unneeded
> >      > but has to be able to be initialized. It shows that the static
> >      > allocation work has succeeded in trimming the workspace at least.
> But
> >      > now we have to account for an empty one. :)
> >
> >     Did you get this error with an unmodified master branch?
> >
> >
> > Not yet. I am updating to 5 first since the last released version was
> from a
> > pre-branching spot and the decision was made to move to the release
> > branch.
> >
> > I am hoping to get it updated to where we can more easily track the
> > master but there are a few things ahead of that.
>
> I would update to the master. We should be close to an RTEMS 6 release.
> Our pre-qualification activity is nearly done.
>

That's not really a schedule option for this next drop.

It is needed long term.

>
> >
> >
> >     Why is the workspace initialized? I tried to arrange everything so
> that
> >     the workspace doesn't get initialized if it is not needed. What
> pulled
> >     in the workspace initialization?
> >
> >
> > Looking at the map from ticker, it looks like it comes from
> > malloc_initialize.c
> >
> > ./../../cpukit/librtemscpu.a(wkspace.o)
> >
> > ./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Area)
> > ./../../cpukit/librtemscpu.a(wkspaceisunifieddefault.o)
> >
> > ./../../cpukit/librtemscpu.a(malloc_initialize.o) (_Workspace_Is_unified)
> >
> > And malloc_initialize.c looks different in 5 versus master.
> >
> > I don't want to get into pulling back a LOT of code. If there is a small
> > patch
> > set that can be backported, I'm ok with that. But a simple fix to let it
> > have a
> > minimum workspace is safe and simple on 5.
> >
> > But this can really occur on 5 so we need at least a fix there.
>
> Back porting things in the workspace and confdefs.h area will be difficult.
>

Then maybe my one line addition is the right work around for 5.

I will make a ticket for 5 and propose my one line addition. Anything else
seems to complicated and risky.

For 6, I'll see if this happens when I test the idle stack allocator.


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