Tue 26 Jun 2007 03:12:10 PM UTC, comment #8:
OK, we all agree this certainly is not a bug in lwIP, so I'm closing it as invalid.
On the other hand, we should have a conversation about how we initialize global (static or not) variables.
|
Tue 26 Jun 2007 09:23:51 AM UTC, comment #7:
Julian Gardner wrote:
> Can we leave this out, trying to code around BROKEN compilers is BAD!!!
That's my opinion, too. I'm only looking at the summary of this and think maybe we can reduce binary size. If we don't want that or it doesn't save anything, we can close this. I certainly wouldn't change anything because of a broken compiler!
|
Tue 26 Jun 2007 08:53:33 AM UTC, comment #6:
As far as I know (at least for gcc), initialized variables go into the data or sdata section, which is present in the binary (initialized values are 'on the disk'). In contrast, uninitialized variables (whether static or not) go into the sbss section, which doesn't need to be located in the binary. There only has to be information about how big that region is and the loader (in my embedded case, a self-made init-code written in assembly) zeros this region on booting.
Thus, we get a bigger text-section (more init code when initializing everything to 0) but smaller data/sdata sections (which can be a huge benefit if big arrays are left out)!
|
Tue 26 Jun 2007 07:37:50 AM UTC, comment #5:
I agree that the primary problem is on my side - my compiler/linker/startup code seems to be broken.
But: There is a lot of predecents in lwip source code.
Please look at:
igmp_init()
ip_reass_init()
mem_init()
netif_init()
raw_init()
stats_init()
tcp_init()
...
...
In my opinion the explicit initialization is a little bit cleaner than implicit one done by startup code.
More over, it think it would be nice if lwip stack has implemented cleanup() functionality -- where all allocated resources are released. Then the complete initialization of global variables inside _init() functions is necessary.
|
Mon 25 Jun 2007 05:57:06 PM UTC, comment #4:
I'm fairly certain the binary would retain the same size, as space for data has to come from somewhere. Perhaps some OSes support some mechanism to initialize a special data section at process load. If someone could show how they could use this mechanism, it would be worthwhile.
|
Mon 25 Jun 2007 05:35:25 PM UTC, comment #3:
I don't like the idea of creating ifdefs for that initialization, it makes the code look ugly! It only could reduce the size of the binary if data wasn't save in the binary as initialized (or am I wrong there?)
|
Mon 25 Jun 2007 04:38:27 PM UTC, comment #2:
This sounds like it's potentially an issue with the linker script, or some other problem. The compiler should support initialization of statics if it
I would be very much against doing this double initialization, as it would impact the startup time of the stack, and increase code size. Adding some #defines to do this would reduce code clarity, but if it's a common issue, may be worth doing for other things. The problem here sounds like a broken environment to me, and not something we should code around in the stack.
|
Mon 25 Jun 2007 04:05:50 PM UTC, comment #1:
Could you also file a bug with the compiler writers?
Have to think about this one as coding around broken compilers is a dangerous precedent to start! Perhaps we can add this is an optional thing (with a suitable #define to control its inclusion).
|
Mon 25 Jun 2007 03:55:57 PM UTC, original submission:
Hello guys,
i'd like to ask if it would be possible to initialize all static/global variables inside xxx_init() functions instead of bank on linked start-up code.
For example one critical i found in sockets.c:
void
lwip_socket_init(void)
{
socksem = sys_sem_new(1);
selectsem = sys_sem_new(1);
----> memset( sockets, 0, sizeof( sockets ) ); <----- please add this line
}
(The compiler i use (TI Code Composer) doesn't initialize some static and global variables correctly. Without this hack sockets[] array is not initialized to zeroes and so i'm not able open any socket )
Thank you very much,
Petr
|