Workspace Initialization Faliure Bug

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Oct 1 17:10:02 UTC 2021


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.

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

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


More information about the devel mailing list