Heavy SysInit Dependency
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...
More information about the devel