Patch for Cross-Reference Phandles

Nathan Whitehorn nwhitehorn at freebsd.org
Sun Sep 15 14:15:06 UTC 2013


On 09/14/13 19:04, Eitan Adler wrote:
> [ *please* bottom post ]
>
> On Sat, Sep 14, 2013 at 7:56 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> ... holy crap. :-)
>>
>> erm, try writing some code that does something with it:
>>
>> int foo[2] = { 0, 0 };
>>
>> main()
>> {
>>      int i;
>>      for (i = 0; i < 2; i++) {
>>          foo[i] = i;
>>      }
>> }
>>
>> .. and then make foo[2] be foo[512] and explicitly set it up to be zero'ed.
>> see what happens.
> With an explicit zeroing:
>
>     text    data     bss     dec     hex filename
>     1572     484      16    2072     818 a.out
>
> Without:
>
>     text    data     bss     dec     hex filename
>     1572     484      16    2072     818 a.out
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"

There's an explanation of this behavior attached to the 
-fno-zero-initialized-in-bss argument to GCC. I've pasted the relevant 
section of the man page below:

        -fno-zero-initialized-in-bss
            If the target supports a BSS section, GCC by default puts 
variables
            that are initialized to zero into BSS.  This can save space 
in the
            resulting code.

            This option turns off this behavior because some programs 
explic-
            itly rely on variables going to the data section.  E.g., so that
            the resulting executable can find the beginning of that section
            and/or make assumptions based on that.

            The default is -fzero-initialized-in-bss.

This is why I wasn't worried about the = 0...
-Nathan


More information about the freebsd-sparc64 mailing list