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