On Fri, Oct 1, 2021, 12:10 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 01/10/2021 16:27, Joel Sherrill wrote: > > > > > > On Fri, Oct 1, 2021, 8:42 AM Sebastian Huber > > <sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@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.hu...@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/ > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel