EmbDev.net

Forum: ARM programming with GCC/GNU tools Linker misplaces non-static .bss globals?


Author: Bill Burgess (auldreekie)
Posted on:

Rate this post
0 useful
not useful
A static global is no problem.  BUT if I remove the "static"
declaration, arm-elf-ld puts the global along with other non-static
globals in a section starting at memory address 0.

You can imagine that this is a Very Bad Thing.

The behavior occurs with a linker command file that looks like the
following.  Interestingly, if the IROM_or_IRAM memory region is omitted
from the command file, the non-static globals are put someplace sane.
But the command file never mentions that anything should be put in
IROM_or_IRAM -- so why does the presence of that informational line
alter how the loader behaves?

I'm aware there are other ways to write a linker command file, but is
this approach wrong?  Why should static or non-static make a difference
to the linker?  Isn't a .bss a .bss?  Well, I'll just remove the
informational IROM_or_IRAM line, it doesn't need to be there anyway.

Thanks for any insights!  --Bill


******** arm-elf-ld command file ********
ENTRY(main)

MEMORY
{
        IROM_or_IRAM (RWX): ORIGIN = 0, LENGTH = 64K /* On-chip */
        IRAM (RWX): ORIGIN = 0x08000000, LENGTH = 64K /* Direct access
*/
}

SECTIONS
{
        .bundle :
        {
                *(.vectors)
                *(.text)
                *(.rodata*)
                *(.glue*)
                _end_rodata = .;
                *(.data)
                *(.bss)
        } > IRAM
}

******** sample code ********
volatile int aGlobal;

int main ()
{
  aGlobal = 1;
  return (aGlobal);
}

******** arm-elf-nm output of the above ********
0800002c T _end_rodata
00000000 B aGlobal <----- HELP!
08000000 T main

******** arm-elf-nm output if "static" inserted before "volatile int"
********
0800002c T _end_rodata
0800002c t aGlobal  <----- THAT'S MORE LIKE IT
08000000 T main

Author: Bill Burgess (auldreekie)
Posted on:

Rate this post
0 useful
not useful
Forgot to mention:  this was using arm-elf-gcc version 4.1.0 and
arm-elf-ld version 2.16.1, both compiled for Mac OS X (downloaded from
this site).  --Bill

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Add *(COMMON) after the *(bss)-Line - this should "help".

Try to generate a map-file if in doubt about section-assignment and
placement. The output might be a little confusing in the beginning but
there is a lot of useful information in it.

Martin Thomas

Author: Bill Burgess (auldreekie)
Posted on:

Rate this post
0 useful
not useful
Martin Thomas wrote:
> Add *(COMMON) after the *(bss)-Line - this should "help".

Ah ha!  So the answer to the question "when is a .bss not a .bss" is,
"when it's a COMMON."  My bad.

Interestingly, the output of arm-elf-nm changed from:

0800002c T _end_rodata
00000000 B aGlobal
08000000 T main

to:

0800002c T _end_rodata
0800002c T aGlobal
08000000 T main

Interesting because nm stops calling aGlobal a "B" for bss and instead
calls it a "T" for text.  I wonder why in neither case does nm call it a
"C" for common, especially as the linker clearly considered it a common.
Well, this is just idle musing, it works and I won't complain!

For the curious, the GNU ld manual section 3.6.4.3 "Input section for
common symbols" goes into this in more detail.  I will contact the
author of the example script I used and suggest he amend it.

> Try to generate a map-file if in doubt about section-assignment and
> placement. The output might be a little confusing in the beginning but
> there is a lot of useful information in it.

I have been doing this quite a bit already but the bad placement of my
few common symbols had eluded me.  I didn't realize that once a symbol
is made common it is no longer considered a .bss.

Many thanks!! --Bill

Author: Guest (Guest)
Posted on:

Rate this post
0 useful
not useful
Bill Burgess wrote:

Hi Bill!

> A static global is no problem.  BUT if I remove the "static"
> declaration, arm-elf-ld puts the global along with other non-static
> globals in a section starting at memory address 0.
>

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.