general comments on sysiinit patches

Sebastian Huber sebastian.huber at
Tue Jan 26 16:02:59 UTC 2016

On 26/01/16 16:51, Joel Sherrill wrote:
> Hi
> I have questions that probably impact all/most of the patches so 
> thought I would start another thread. Then it is just detailed review 
> of the individual patches.
> + We have used EXTERN to avoid duplicating extern and instantiating 
> data. You appear to have completely removed that pattern with no 
> discussion of changing the coding style.  I really don't like 
> duplication of the information.

There is no duplicate information. We have exactly one declaration and 
one definition. The compiler checks that they harmonize. Its necessary 
to move the definitions to the right module, so that the linker can do 
its job and add the right initialization items.

This extern stuff is not mentioned here:

> + Do you have any size metrics for current --disable-posix on a BSP 
> with function sections enabled versus this new way?

No, I was not interested in this comparison since my goal is to always 
enable POSIX in the long run. The size will drop a bit. I used the SIS 
BSP for comparison since it uses the function/data sections for quite a 

> + What impact does this have on BSP linkcmds? I am guessing since you 
> already added all the rtems sysinit magic, this will just work with no 
> issues. And we are stuck with missing function section KEEP's.

The linkcmds relevant patch sets are these and they are in place since 
September 2015:

> Not opposed to doing the sysinit. I would just like to know what the 
> size delta is between the two solutions.  I am guessing this and 
> function sections will be consistently smaller as compared to when 
> POSIX is currently enabled.
> --joel
> _______________________________________________
> devel mailing list
> devel at

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list