Heavy SysInit Dependency

[Joel Sherrill]

On Wed, May 19, 2021 at 12:27 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello Joel,
>
> On 18/05/2021 23:40, Joel Sherrill wrote:
> > Hi
> >
> > In working with Alex to reduce the minimum on his new BSP, we noticed
> > that it is easy for a BSP to accidentally trip up and end up with a
> > minimum.exe that is as much as 2x over what it should be. I have looked
> > at a few BSPs and seen a handful of issues so far. I have patches
> > pending for some. This particular issue I think indicates a dependency
> > path that is too heavy. I spotted this on powerpc/psim and likely
> > impacts a number of BSPs. I made two minor changes reduced the size of
> > minimum.exe as shown below
> >
> >       text    data     bss     dec     hex filename
> >    66616   11848 268356980 268435444     ffffff4 minimum.exe
> >    45064    5884 268384476 268435424     fffffe0 minimum.exe
> >
> > FWIW That 45K is larger than the ARM or MIPS BSPs I looked at but seems
> > reasonable due to all the PPC helper and IRQ code pulled in.
> >
> > psim  does two things that the arm and mips BSPs I looked at do not. It
> > uses the powerpc shared sbrk.c and it calls malloc() from its
> > irq_init.c. malloc() and sbrk() set errno. Commenting out setting errno
> > in those two methods is what resulted in 21.5K text and 6K data saved.
>
> we have an rtems_malloc() and rtems_calloc() which do not set errno.
>

OK. This and not setting errno in the PPC sbrk() are sufficient to break
this
particular chain.

This means that BSPs and device drivers need to be careful not to call
malloc().


>
> >
> > I think setting errno doesn't directly add this much code but the
> > sysinit dependency chain it trips ends up pulling in getreent,
> > rtems_libio_init, rtems_libio_post_driver (opening /dev/console), open,
> > atexit(), close(), rtems_filesystem_do_unmount() and a host of other
> > things. I am not sure of the exact order of the chain but that's the end
> > result.I do think it starts with getreent though.
>
> Yes, if you use __getreent() with
>
> #define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
>
> then a lot of stuff is pulled in.
>
> If you don't use this option, then a lot of stuff is pulled in by the
> Newlib extensions.
>

Yeah. But if you use any method with errno, you get all this. I know the
reent structure has to be initialized but why did it trigger opening
/dev/console? The console device wasn't configured. Can the post driver
hook dependency be cleaved from this chain?

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/libio_init.c#n69

I think that dependency is only needed if you configure the console
device driver. Shouldn't the sysinit for the post driver hook be part of
configuring the console or simple console?

https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/console.h
https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/iodrivers.h




> >
> > It would be nice to call a method that uses errno without automatically
> > pulling in this much baggage via a long dependency chain.
> >
> > Alternatively, the BSPs should use a malloc alternative that does not
> > set errno. And our sbrk is only used in one place so it could simply not
> > set errno.
> >
> > Fixing the dependency chain is the preferred solution.
>
> I am not sure how the dependency chain can be fixed with the current
> struct _reent approach of Newlib. A modern approach would be to replace
> this structure with individual thread-local objects. This would be
> technically feasible, however, a lot of work.
>

How about just not opening /dev/console? This will eliminate a lot of the
chain.

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/open_dev_console.c

That pulls in open, atexit, and close as a starting point. libio_init by
itself
without the link to the post driver open(/dev/console) doesn't look that bad

--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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210519/0676a638/attachment-0001.html>