This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: COMMON symbols...


----Original Message----
>From: Nick Clifton
>Sent: 01 April 2005 14:41

> Hi Dave,
> 
>>   So I think that ld isn't zero-filling the space it allocates to the
>> common symbols, but just letting them take whatever values happen to be
>> in the host memory space that has been allocated by the linker to build
>> up the output section. 

> I strongly suspect that this is a linker "feature" in that it has never
> had to zero-fill the file space that is going to be used for common
> symbols because it assumes that they are always going to be going into a
>   section with the SHT_NOBITS flag set.  ie this is a bug and the linker
> ought to check for this and zero the memory it writes out if necessary.

  Right, it's no great surprise that it hasn't been tried a whole lot
before, although I'm surprised it works for .bss but not .common - they both
have SHT_NOBITS, don't they?  I wondered perhaps if there's some
special-cased handling of the COMMON (pseudo-)section.  I'll take a closer
look.

  In fact, considering that COMMON data is essentially uninitialised data,
you could probably make a case that the linker is behaving reasonably, and
it's the compiler that is wrong to place variables in COMMON when the C spec
requires all data of static storage duration to be zero-initialised even
when not explicitly initialised.... but it's a bit late to go back over that
historical decision now!

> Anyway the only way that I can think of to fix this in a linker script
> is to use overlays.  This *might* work, but I have not tried it.

  Sounds scary!

> Incidentally if you fix -fno-common you could then add the
> -ffno-zero-initialized-in-bss switch and then not have to modify your
> linker script at all....

  Yes, it looks like I'll have to fix -fno-common, but I don't think I'll
need the -fno-zero..... switch in any case; the bss data _does_ get zeroed
in the output section, so just materialising the symbols into actual .bss
space objects rather than leaving them as common-space allocations would
probably do the trick for me all by itself.  Ta.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]