COMMON symbols...

["Dave Korn" <dave dot korn at artimi dot com>]

... (and indeed explicitly-zero-initialised variables) normally go into the
.bss section, which is then cleared to zero by the runtime startup.

  But I want to place all my common and bss directly into the .data section,
because I'm coding for a small embedded system where the entire memory space
is initialised with the (raw) contents extracted from my (elf) object file
at startup, so it's a waste of time zeroing the memory range occupied by the
bss section; I want the object file to contain explicit zeros for that area
of memory.

  The linker script is fairly simple: here's a summary, although I've
snipped out an extraneous memory region and its corresponding
SECTIONS-directive entry.

MEMORY
{
  text     (rwx) : ORIGIN = 0x10000, LENGTH = 0x8000
  data     (rw)  : ORIGIN = 0x00000, LENGTH = 0x1000
}

SECTIONS
{
  . = 0;
  .text :
  {
    CREATE_OBJECT_SYMBOLS
    *(.text*)
    *(.rodata*)
    etext = ALIGN(1);
  } > text
  . = ALIGN(1);
  .data :
  {
    /*
    ** First data location is reserved to check for over-writing (being
located at zero)
    */
    PROVIDE(_firstDataLocation = .);
    . = . + 4;
    *(.data*)
    CONSTRUCTORS
    edata  =  .;
  } > data = 0
  .bss :
  {
   *(.bss*)
   *(COMMON)
   end = . ;
  } > data = 0
}

  Anyway, I tried moving the *(.bss*) and *(COMMON) entries from their
current location to just between the "CONSTRUCTORS" and "edata = ."
directives.  This only half-works, alas.

  Although both bss and common symbols now end up in the data section, only
the space allocated to the bss symbols is zero-filled; the space allocated
to the common symbols ends up full of garbage; some binary, some printable
ascii that is recognizable as the names of symbols and files involved in the
link.

  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.

  Is there any way to work around this?  I couldn't get useful results with
the FILL expressions, which I suppose makes sense because the space is used.
And I couldn't get the FORCE_COMMON_ALLOCATION directive or -d switch to
help me out either.

  Does anyone know of a way to get the result I want from the linker?
Neither the common nor the bss variables have any content supplied to them
from the input object file, yet ld zero-fills the space it allocates to bss
but not the space it allocates to common.  It should be possible to persuade
it to zero-fill both of them, but maybe I'll have to hack it around a bit?

  (And before you ask, I can't just give gcc -fno-common, even though that
would move the common symbols into bss for me and hence get them
zero-filled, because the option's  a bit b0rked somewhere in my toolchain
and causes gcc to emit invalid assembler directives.  Yes, that's probably
quite simple to fix and I almost certainly should do so anyway, but while
looking into it I got curious if I could teach the linker to do what I
wanted.)


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