Heavy SysInit Dependency
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed May 19 05:27:53 UTC 2021
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.
>
> 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.
>
> 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.
--
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