This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: COMMON symbols...
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Nick Clifton'" <nickc at redhat dot com>
- Cc: <binutils at sourceware dot org>
- Date: Fri, 1 Apr 2005 15:09:38 +0100
- Subject: 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....