Compiler won't create .bss section

[JonathanJones]

Hello,

I'm Using CodeWarrior for StarCore v2.7.2.

I can't get the compiler to create a .bss section.  When I declare an uninitialized variable, say

   unsigned int blah[50];

it gets placed in the .data section, initialized to zero.  I don't like this, because it increases the size of my .eld file needlessly.

I have tried using an Icode options file containing the following:

   Uninit_And_Zeroed_Globals_In_Bss=TRUE
   Uninit_Globals_In_Bss=TRUE

This seems to have no effect.  Could this be being overridden somewhere?  Any other ideas?

Thanks,

Jonathan Jones

[CrasyCat]

Hello

I do not have a lot of experience with StarCore V2.5.2 tools, but hopefully my experience with V2.6 can help a little bit.

Actually with V2.6 and V2.7 tools, the options

   Uninit_And_Zeroed_Globals_In_Bss=TRUE
   Uninit_Globals_In_Bss=TRUE

Are used in an application configuration file not in an ICODE option file.

Can you try to create an application configuration file containing the following text:

configuration
  view test
     Uninit_And_Zeroed_Globals_In_Bss=TRUE
     Uninit_Globals_In_Bss=TRUE
  end view
end configuration

And add following options to your command line -ma "myconf.appli" -view test where myconf.appli is the name of your configuration file.

I hope this helps

CrasyCat

[JonathanJones]

Thanks for your help.

I tried your suggestion, and it had no effect.

In the Enterprise C Compiler Manual (v2.6 -- revised 24 Sept. 2004), the Uninit_And_Zeroed_Globals_In_Bss and Uninit_Globals_In_Bss options are listed in Table 5.6.  Regarding this table, it says:

Table 5.6 lists public Icode options, which you can use in your application configuration files. (You also can set these options in Icode option files.)

So, now I have tried the options in both files, without effect.

I have also tried running the compiler from the DOS command line with a minimal command line, with the same result.

I am stumped.  Any other ideas?

Thanks,

Jonathan Jones

[CrasyCat]

Hello

Sorry I did not check my answer carefully enough last time .

In fact the application configuration file should look like:

configuration
  view test
     Uninit_And_Zeroed_Globals_To_Bss = TRUE
     Uninit_Globals_To_Bss=TRUE

  end view
end configuration

I have tested that on V2.6 & V2.7 and it works perfectly.

Sorry for the confusion last week.

Crasycat

[JonathanJones]

Yep, that does the trick.  Thanks!

Looks to be a documentation error.  It says "...In_Bss" in my copy of the compiler manual, and in some (but not all) of the Release Notes files.

I wonder why this option has to be turned on.  Why isn't it the default behavior?

[CrasyCat]

Hello

This is a legacy behavior. It has been implemented that way at first. 
We are thinking about activating that per default in a future release of the compiler. 

Basically some customer wants to separate initialized and uninitialized data some other do not want.

But I agree with you the ELF file format usually purpose to keep them separate.

Around release notes, the option name have been adjusted in V2.7.

CrasyCat

[JonathanJones]

Interesting.

Speaking of the ELF format and future plans, is there any intention to support STB_WEAK binding in the future?  It looks like the linker currently treats these symbols as STB_GLOBAL.  I have had to write my own "pre-linker" that strips conflicting symbols out of .eln files before linking.

Ideally, what I would like to be able to do is to specify on the linker command line (or in the .lcf file) that the global symbols in one particular .eln file should take precedence over the conflicting global symbols in all other .eln files.  An alternate solution would be a compiler option to make all (or some) global symbols "weak" when creating the .eln file.

And of course the dead-code-stripping logic needs to be aware that if a "weak" symbol is superseded, the code it references should be stripped.

Perhaps you can think of a way to do what I need to do using the current compiler/linker.  Basically, I want to "compile against" a pre-existing .eld file.  Any functions that are present in the pre-existing .eld file should supersede the functions of the same name that appear in the .eln files I'm linking.

Thanks for your time.

[CrasyCat]

Hello

Did you try the linker option -allow-multipledefinition?

According to the manual "SC100 linker reference.pdf",
option -allow-multipledefinition specifies using the first of multiple definitions for a symbol, although the linker generates a warning. (Without this option, multiple definitions are a fatal error).

I did not try it myself so far, but it could be worth a try :smileyhappy:

I have to check around supporting STB_WEAK in the future.

crosscut

[JonathanJones]

Yeah, I've played around a little with -allow-multiple-definitions.  But in my case, having the linker spit out hundreds of warning messages isn't a very good solution. 

Plus, I really want to be able to specify on a per-symbol basis which one takes precedence.  I can't do this if the precedence is determined by the order of the object files on the command line.

[CrasyCat]

Hello

I have made a small test, where I have re-implemented strcpy string function some other way.

Without option -Xlnk "-allow-multiple-definition", I cannot link my application due to redefinition of strcpy.

As soon as I add this option I am able to link. So this should work out.

I am not seeing and warning messages (even when I check the box "Display all errors and warnings" in the Enterprise Linker panel.

Am I missing something here?

CrasyCat