buglwIP - A Lightweight TCP/IP stack - Bugs: bug #20254, Initializing static/global...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #20254: Initializing static/global variables

Submitted by:  Petr Cernin <cerninp>
Submitted on:  Mon 25 Jun 2007 03:55:57 PM UTC  
 
Category: sockets/netconnSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: None

(Jump to the original submission Jump to the original submission)

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.

Simon Goldschmidt <goldsimon>
Project Administrator
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!

Simon Goldschmidt <goldsimon>
Project Administrator
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)!

Simon Goldschmidt <goldsimon>
Project Administrator
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.

Petr Cernin <cerninp>
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.

Thomas Taranowski <taranowski>
Project Member
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?)

Simon Goldschmidt <goldsimon>
Project Administrator
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.

Thomas Taranowski <taranowski>
Project Member
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).

Kieran Mansley <kieranm>
Project Administrator
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

Petr Cernin <cerninp>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by goldsimon (Posted a comment)
  • -unavailable- added by taranowski (Posted a comment)
  • -unavailable- added by kieranm (Posted a comment)
  • -unavailable- added by cerninp (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 26 Jun 2007 03:12:10 PM UTCgoldsimonStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1