Heavy SysInit Dependency

Joel Sherrill joel at rtems.org
Tue May 18 21:40:15 UTC 2021


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.

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.

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

Fixing the dependency chain is the preferred solution.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210518/68f61c5c/attachment.html>

More information about the devel mailing list