common symbols

common symbols

[ali hagigat]

My question is in relation with GNU ld. What is common symbol?
How the linker considers space for common symbols, would you please
give me an example?
is a label common symbol?
Regards

Re: common symbols

[Alan Modra]

On Sat, Feb 26, 2011 at 02:27:17PM +0330, ali hagigat wrote:
> My question is in relation with GNU ld. What is common symbol?

google "linker common symbol"

-- 
Alan Modra
Australia Development Lab, IBM

Re: common symbols

[Erik Christiansen]

On Sat, Feb 26, 2011 at 02:27:17PM +0330, ali hagigat wrote:
> My question is in relation with GNU ld. What is common symbol?
> How the linker considers space for common symbols, would you please
> give me an example?
> is a label common symbol?
> Regards

There is a useful amount of explanation (to begin with) at section:

3.6.4.3 Input Section for Common Symbols

of the info file for ld. (At least, ISTR that's where I snaffled the
plaintext file I use in preference to menued monkeyshines.)

Sadly, "info ld" only shows the manpage if you're on a ubuntu system.
There is equivalent content here, however:

http://sourceware.org/binutils/docs-2.21/ld/index.html

Using that text, some googling, and some experiments, has been enough to
answer an awful lot of questions, I've found. ;-)

Erik

-- 
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite."
                           - Bertrand Russell, _Sceptical_Essays_, 1928

Re: common symbols

[Matthias Klose]

On 26.02.2011 12:30, Erik Christiansen wrote:
> Sadly, "info ld" only shows the manpage if you're on a ubuntu system.
> There is equivalent content here, however:

apt-get install binutils-doc

Re: common symbols

[Erik Christiansen]

On Sat, Feb 26, 2011 at 09:38:51PM +0100, Matthias Klose wrote:
> On 26.02.2011 12:30, Erik Christiansen wrote:
>> Sadly, "info ld" only shows the manpage if you're on a ubuntu system.
>> There is equivalent content here, however:
>
> apt-get install binutils-doc

Vielen Dank, muchas gracias, and many thanks, Matthias.
(It is beyond time to update the old text copy I have.)

Erik

Re: common symbols

[ali hagigat]

As far as I understood "common symbol" is defined and it is part of
the input section named, COMMON. But that depends on assembler. For
GNU as, it seems that we can not define common symbol!!

On Sat, Feb 26, 2011 at 2:27 PM, ali hagigat <hagigatali@gmail.com> wrote:
> My question is in relation with GNU ld. What is common symbol?
> How the linker considers space for common symbols, would you please
> give me an example?
> is a label common symbol?
> Regards
>

Re: common symbols

[Erik Christiansen]

On Mon, Feb 28, 2011 at 11:06:33AM +0330, ali hagigat wrote:
> As far as I understood "common symbol" is defined and it is part of
> the input section named, COMMON. But that depends on assembler. For
> GNU as, it seems that we can not define common symbol!!

For which target is gas not heeding your attempts?
What assembler syntax are you using to specify the input section of your
test code?
What are the error messages?

If your linker script lacks a "COMMON" input section, you are free to
add it. The first linker script I glanced at has it by default, and not
surprisingly, it is in the .bss output section.

Erik

-- 
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite."
                           - Bertrand Russell, _Sceptical_Essays_, 1928

Re: common symbols

[ali hagigat]

I use GNU gcc, as, ld. I can define input section COMMON but I want
gcc or as produce common symbols automatically. I never saw gcc
produce any COMMON section automatically by C programs.

On Mon, Feb 28, 2011 at 11:37 AM, Erik Christiansen
<dvalin@internode.on.net> wrote:
> On Mon, Feb 28, 2011 at 11:06:33AM +0330, ali hagigat wrote:
>> As far as I understood "common symbol" is defined and it is part of
>> the input section named, COMMON. But that depends on assembler. For
>> GNU as, it seems that we can not define common symbol!!
>
> For which target is gas not heeding your attempts?
> What assembler syntax are you using to specify the input section of your
> test code?
> What are the error messages?
>
> If your linker script lacks a "COMMON" input section, you are free to
> add it. The first linker script I glanced at has it by default, and not
> surprisingly, it is in the .bss output section.
>
> Erik
>
> --
> "What is wanted is not the will to believe, but the will to find out,
> which is the exact opposite."
>                           - Bertrand Russell, _Sceptical_Essays_, 1928
>

Re: common symbols

[Ian Lance Taylor]

ali hagigat <hagigatali@gmail.com> writes:

> As far as I understood "common symbol" is defined and it is part of
> the input section named, COMMON. But that depends on assembler. For
> GNU as, it seems that we can not define common symbol!!

A common symbol is distinct from a definition or a reference.  It has
nothing to do with an input section named COMMON.  The linker script
language does permit you to pretend that all common symbols are in an
input section named COMMON, but that is just a convenience for the
linker script language.

In GNU as you can define a common symbol using the .comm pseudo-op, as
documented in the assembler manual.

Please consider doing more research before asking your questions.
Thanks.

Ian

RE: COMMON symbols...

[Dave Korn]

----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....

Re: COMMON symbols...

[Nick Clifton]

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.
> 
>   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?

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.

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.

>   (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

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....

Cheers
   Nick

COMMON symbols...

[Dave Korn]

... (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....