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

Submitter:  Petr Cernin <cerninp>
Submitted:  Mon 25 Jun 2007 03:55:57 PM UTC
   
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member
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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-26 goldsimon StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code