gcc .data and .bss address space

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
What is the compiler option and/or directive to change the "Addr" field of elf file?

If i use:
        .bss
        .data
        .org 0x100000
it simply increase the "Off" and create a huge file.  
The chip's ram is at 0x20000000

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 0009f4 00  AX  0   0  4
  [ 2] .rel.text         REL             00000000 001e54 000028 08   I 19   1  4
  [ 3] .data             PROGBITS        00000000 000a28 000000 00  WA  0   0  1
  [ 4] .bss              NOBITS          00000000 000a28 000000 00  WA  0   0  1
  [ 5] .rodata           PROGBITS        00000000 000a28 00004c 00   A  0   0  4
user@user:~/mcu$ ls -l stm.elf
-rw-rw-r-- 1 user user 9792 May  3 07:23 stm.elf
user@user:~/mcu$ readelf -S stm.elf | head
  [ 4] .bss              NOBITS          00000000 100a28 000000 00  WA  0   0  1
  [ 5] .rodata           PROGBITS        00000000 100a28 00004c 00   A  0   0  4
user@user:~/mcu$ ls -l stm.elf
-rw-rw-r-- 1 user user 1058368 May  3 07:23 stm.elf

Re: gcc .data and .bss address space
On 3.5.21 17.35, Ed Lee wrote:
Quoted text here. Click to load it


The tool for it is the loader script file. Please get the GNU ld manual
from the binutils documents.

Which STM chip (and maybe demo card) are you using?
What are the memory ranges you want?

--  

-TV


Re: gcc .data and .bss address space
On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:
Quoted text here. Click to load it

But gcc-as does not know about the loader script, and send the global variables to the wrong place.

Quoted text here. Click to load it

STM32F411: flash at 0 to 0x8000000, ram at 0x2000000 to 0x2002000.

If i use .org 0x2000000 for .data and .bss.  Every ROM image is at least 33Mbytes.

I am just avoiding globals for now.  But someone must have solved this problem somewhere.

Re: gcc .data and .bss address space
On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:
Quoted text here. Click to load it

Sorry,
STM32F411: flash at 0 to 0x80000, ram at 0x20000000 to 0x20020000.  

Re: gcc .data and .bss address space
On 3.5.2021 22:14 PM, Ed Lee wrote:
Quoted text here. Click to load it


The way to feed the linker script is the compiler switch
-Wl,-T,myscript.ld

There is a good reason to add -Wl,-Map=myfile.map
to the compiler switches to see what the linker has done.

Please get the compiler and linker manuals and read them.

To set up the runtime system, you need a routine at the very
start to copy the initial values from the ROM to the RAM for
the .data section.

Here is a model script, which is for raw metal startup:

--- clip clip ---

/*   Linker script model for STM32F411    */
/*   $Id: myscript.ld tauno $  */

/*   Memory regions, STM32F411   */

MEMORY
    {
    flash (rx) : org = 0x08000000, len = 512k
    ram   (wx) : org = 0x20000000, len = 128k
    }

/*   ELF program headers   */

/*   There is a need to specify separately from the default,
      as the default setup extends the load size down to a
      32 KiB boundary, clobbering the boot loader when
      programming with OpenOCD   */

PHDRS
    {
    text   PT_LOAD ;  /* Code and constants */
    data   PT_LOAD ;  /* Initialized read / write data */
    bss    PT_LOAD ;  /* R/W data */
    }

/*   Linkage instructions   */

SECTIONS
    {
    /*   Exception vector in ROM, keep at offset 0   */

    .romvec ORIGIN(flash) :
        {
        KEEP(*(.romvec))  /* binary file header */
        KEEP(*(.ident))   /* program ID if present */
        . = ALIGN(4);
        } > flash : text = 0xff

    /*   Code and constants   */

    .text :
        {
        /* code */

        *(.text*)

        /* other read-only data */

        *(.rodata)
        *(.rodata.*)
        *(.glue_7*)
        *(.vfp11_veneer)
        *(.v4_bx)
        *(.iplt)
        *(.rel.dyn)
        . = ALIGN(4);
        } > flash : text = 0xff

    /*  Initialized data with ROM copy   */

    .data (NOLOAD) :
        {
        _rwstart = . ;
        *(.ramcode)
        *(.data*)
        . = ALIGN(4);
        _rwend = . ;
        } > ram AT > flash : data

    /*  Zero-init data   */

    .bss :
        {
        _zistart = . ;
        *(.bss*)
        *(COMMON)
        . = ALIGN(4);
        _ziend = . ;
        } > ram AT > ram : bss
    }
    
/*   Section boundaries   */

_ldata = LOADADDR(.data) ;

_rostart = ADDR(.romvec) ;
_roend = LOADADDR(.data) + SIZEOF(.data) ;

_rwstart = ADDR(.data) ;
_rwend = ADDR(.data) + SIZEOF(.data) ;

_zistart = ADDR(.bss) ;
_ziend = ADDR(.bss) + SIZEOF(.bss) ;

/*   Initial stack pointer   */
/*   Needs to be at an 8 byte boundary for EABI specification */

_stktop = ALIGN(ORIGIN(ram) + LENGTH(ram) - 7, 8) ;

/*   Startup location   */

EXTERN(start)
ENTRY(start)

--- clip clip ---

--  

-TV

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:
Quoted text here. Click to load it


If you put this in gcc-cc command, it will pass it to gcc-ld, gcc-as will not accept this option.  So, gcc-as put global variables at 0x0p and linker put them at 0x2000p (p=page of 0x0000 bytes).

Quoted text here. Click to load it

Yes, and the assembler need to know to compile codes for address 0x2000p but put it near 0x0p.  It's currently ignoring the linking instructions.

If i use ".text .org 0x100, .data .org 0x2000p and.bss .org 0x2001p", it create a 500 Mbytes file with holes (zeros).  So, i need to punch it out for the rom image.

,bss is technically incorrect, because it is saying to zero out all memory between 0x0p and 0x2001p, but at least it doesn't do anything and doesn't take up any storage space.

punch stm.xlf
Section   Address  Offset   Size
   .text  00000000 00000034 00000a10   fe ff ff ea 04 b0 2d e5
   .data  00000000 00000a44 20000004  78 56 34 12 fa 3f 00 20
    .bss  00000000 20010a48 20010004  
 .rodata  00000000 20010a48 00000048  fa 3f 00 20 04 01 00 00

punch stm.elf stm.xlf
Section   Address  Offset   Size
   .text  00000100 00000034 00000910  fe ff ff ea 04 b0 2d e5
   .data  20000000 e0000a44 00000004  78 56 34 12
    .bss  20010000 00000a48 00000004  
 .rodata  00000000 00001a48 00000048  fa 3f 00 20 04 01 00 00

punch rewrite the elf sections when a third argument is provided.

Re: gcc .data and .bss address space
On 4.5.21 16.32, Ed Lee wrote:
Quoted text here. Click to load it


Please show the exact command line you're using for the as, so we can
correct it. If you're using GCC to assemble a .s or .S file, the
normal switches apply.

There is a good reason to use the assembler only to create the .o file
and make the linking in a separate step (using gcc again).

Please remove the .org directives from your assembler code. The linker
script is the proper way to locate various program sections. If you
want to have a piece of code or data located separately, create an
own section for the blob and tell the linker where it's wanted to go.
For an example, see the section .romvec in the linker script.

What is punch? A STM weirdness?

The GNU way to look at ELF files is objdump (arm-none-elf-objdump,  
maybe). objdump -h myfile.elf is the way to look in. Besides, you
should have the information already in the link map, if you request
it from the linker.

--  

-TV

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:
Quoted text here. Click to load it
field of elf file?  
Quoted text here. Click to load it
nual  
Quoted text here. Click to load it
l variables to the wrong place.  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
ast 33Mbytes.  
Quoted text here. Click to load it
s problem somewhere.  
Quoted text here. Click to load it
ll not accept this option. So, gcc-as put global variables at 0x0p and link
er put them at 0x2000p (p=page of 0x0000 bytes).  
Quoted text here. Click to load it
p but put it near 0x0p. It's currently ignoring the linking instructions.
  
Quoted text here. Click to load it
t create a 500 Mbytes file with holes (zeros). So, i need to punch it out f
or the rom image.  
Quoted text here. Click to load it
ory between 0x0p and 0x2001p, but at least it doesn't do anything and doesn
't take up any storage space.  
Quoted text here. Click to load it

user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld

user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld
arm-none-eabi-as: unrecognized option '-T'

user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld

Quoted text here. Click to load it

But gcc-as generates the wrong addresses with memory access.

Quoted text here. Click to load it

Punch is a custom program to reduce the holely file by mmu instructions fro
m the project.  This still require an intermediate 500M bytes file to gener
ate the virtual address sections, then map to the physical address sections
.  Of course, the proper way to do it is to patch gcc with the mmu instruct
ions.

mmu instructions:

.rodata 0 to 0x100  (boot and interrupt vectors)
.text 0x100 to 0x2000p
.data  0x2000p to 0x2001p
.bss 0x2001p to 0x2002p

Quoted text here. Click to load it

Punch generates the same information as objdump and readelf, but only the 4
 sections necessary.  Future version (TODO) is to remap the sections accord
ing to the mmu instructions.

Re: gcc .data and .bss address space
On 4.5.21 18.14, Ed Lee wrote:

Quoted text here. Click to load it

You did not look at the command:
arm-none-eabi-gcc -g -nostdlib -Wl,-T,stm.ld -Wl,-Map=main.map \
-o linked.elf main.s

Quoted text here. Click to load it

The output of as (.o) is a sybolic binary file, which is the located
by ld.

I would do the job in two steps, to keep things simple:

arm-none-eabi-gcc -g -c -Wl,main.lst main.s
arm-none-eabi-gcc -g -nostdlib -Wl,-T,stm.ld -Wl,-Map=main.map \
-o linked.elf main.o

To create a ROM image (e.g. Intel hex):

arm-none-eabi-objcopy -O ihex linked.elf linked.hex

Quoted text here. Click to load it

You do not need a special program to reduce the linked file, just
a proper linker script. You can use objdump with the -j switch to
pick the desired sections from the absolute ELF file.

--  

-TV


Re: gcc .data and .bss address space
On 4.5.21 18.14, Ed Lee wrote:
Quoted text here. Click to load it

The memory control unit in STM32F411 is not a MMU, but a MPU,
memory protection unit. You can easily get the section limits
from the linker script. A symbol defined in a linker script is
available to the code as an external address.

Your list corresponds roughly to what I have in the linker
script, your .rodata is called .romvec in the script.
.rodata is not a good name for the vector section, as it will
contain compiler-generated constants. For the startup vector,
you need to define two 32-bit constants into a separately
named section (I used .romvec).

In assembly code, the section is named simply with the
.section directive.

In C code the section is named with the __attribute__(())
declaration on the constant array.

--  

-TV


Re: gcc .data and .bss address space
Quoted text here. Click to load it


Looks OK
  
Quoted text here. Click to load it

Given correct main.o shoud be OK.

Quoted text here. Click to load it

If you write correct asm your addresses will be correct.

Look at following:
----------------<cut here>--------------------

        .syntax unified
        .cpu cortex-m4

        .text
.Lstack:
        .word 0x20020000
.Lstart:
        .word start

        .text
        .org 512
        .global start
        .thumb
        .thumb_func
        .type   start, %function
start:
        ldr     r2, .L4
.L2:
        ldr     r3, [r2]
        adds    r3, r3, #1
        str     r3, [r2]
        b       .L2
        .align  2
.L4:
        .word   c

        .comm   c,4,4

----------------<cut here>--------------------

Store to anull.s and do:

arm-none-eabi-as -c anull.s -o anull.o
arm-none-eabi-ld anull.o -T f411.ld -o anull.elf

AFAICS it generates .elf file as you want.  There is little
weirdness with interrupt vectors: Tauno Voipio wanted vectors
in separate section but I normally put them in .text,
so using his linker script with my asm gives empty .romvec.
Above I put just two vectors (should be enough to run) but
in something serious there would be a subsection (written
in C).

--  
                              Waldek Hebisch

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, snipped-for-privacy@math.uni.wroc.pl wrote:
Quoted text here. Click to load it

r2 = 550 (aprox)

Quoted text here. Click to load it

r3 = c

Quoted text here. Click to load it

r3 = d

Quoted text here. Click to load it

store d to memory location 550

Segmentation violation.  Can't write to ROM.

Quoted text here. Click to load it

Re: gcc .data and .bss address space
Quoted text here. Click to load it

Wrong, this is PC relative load that load value stored at .L4,
that is 0x20000000 (address of c).

Quoted text here. Click to load it

No, this is store to RAM (to c).

Quoted text here. Click to load it

--  
                              Waldek Hebisch

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, snipped-for-privacy@math.uni.wroc.pl wrote:
Quoted text here. Click to load it

PC is approx 520.  The assembler does not know about 0x20000000.

Re: gcc .data and .bss address space
Quoted text here. Click to load it

Have you tried provided commands?  There is also objdump, run

arm-none-eabi-objdump -D anull.elf

to see what is in .elf file.  And compare with

arm-none-eabi-objdump -D anull.o

And yes, assember produces relocatable code and does not know
addresses.  It is linker job to put addresses into ELF executable.

--  
                              Waldek Hebisch

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 5:21:46 PM UTC-7, snipped-for-privacy@math.uni.wroc.pl wrote:
Quoted text here. Click to load it

Yes, i have been looking at object files, elf and bin files, with objdump, readelf, od and hexdump.  The linker relocates the data to the ram address, but does not change the content, which is still pointing to the rom address.

I am just trying to convince myself how is that possible to work without the assembler knowing the actual physical address of ram.

Re: gcc .data and .bss address space
On 5/4/2021 6:06 PM, Ed Lee wrote:
Quoted text here. Click to load it

"RAM" is just a set of one (or more) labels that you have located in a data
segment.

How does the assembler know how to access a subroutine that you've defined IN
ANOTHER MODULE?

The linkage editor knows how to resolve cross-module labels.
So, you can reference a location in "ROM" or "RAM" without
the actual instruction knowing the difference.

The loader maps addresses of sections to physical addresses.

So, you end up with a binary that has been *bound* to a specific
set of constraints -- inter-module and inter-section.

Re: gcc .data and .bss address space
On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:
Quoted text here. Click to load it
t the  
Quoted text here. Click to load it
ta  
Quoted text here. Click to load it
d IN  
Quoted text here. Click to load it

The compiler tell the linker to relocate address of another module, as well
 as address of data variables.  But it does not change the content of such  
variables, even if they are relocated to another address space.  In this ca
se, if the assembler is using the content of the variable pointing to the d
ata variable's address, it would remain in the rom space.

Re: gcc .data and .bss address space
On 5/4/2021 6:33 PM, Ed Lee wrote:
Quoted text here. Click to load it

If you define a variable in a section that is bound to a ROM portion
of your address space, then the variable *is* in the ROM -- effectively
"immutable".  (this is useful in preference to #defines)

If it is *really* a "variable", then you have two types to deal with:
initialized and uninitialized.  (ignoring stack frames)

An uninitialized variable just takes up space in RAM; there is no
need to store the "initial value" for that variable.  You just
need to know where -- in the .bss segment -- the variable is
implemented.  You can reduce the size of an executable by putting
all "uninitialized" data into a single .bss (conventionally) section.

The startup code typically "zeroes" all of the bss segment.  Note
that is usually does this as efficiently as possible -- bzero()
just jams zeroes into a *region* of memory with no concern over
the "variable boundaries" within it.

On the other hand, *initialized* data (variables) need to take up space
in ROM (for the initial value) as well as RAM (for the *actual* variable
which can be ALTERED, at run time).

These (the "live" variables modifiable at run time) reside in the .data
segment.

The constant values with which they should be initialized are copied
into this segment by the startup code -- before "your" code runs.
Again, the startup code doesn't have to respect the individual
boundaries of variables; it just has to ensure that, once done,
every variable referenced in that section has the correct
initial value.

[E.g., I can jam 0x41424344 into a word and this might correspond to
four characters of a string ("ABCD"), two shorts (0x4142 and x4344),
etc.  The initialization code will just copy a block of constants
into the writable memory set aside for those "initialized data" as
efficiently as possible]

Actual "const" values are stored in a .rodata segment which, ideally,
can not be altered (but, that's up to the hardware).

You don't care where *the* constant value is stored that will be used to
initialize "foo" in "int foo = 123;".  That value will be copied *into*
foo before your code runs -- ONCE!

But, you *do* care where "foo" actually resides because your code will
reference it -- REPEATEDLY.

Using these segments/sections, you can strategically rearrange
where your resources are allocated.  I recall a legacy compiler that
placed a 64KB limit on the amount of data that were supported.
But, treated consts as a *separate* 64KB segment.  So, I could
effectively have 128KB of "data" addressable without exceeding
the limitations of the compiler.

Re: gcc .data and .bss address space
Quoted text here. Click to load it

What you wrote is confused.  After assembly main part of .o is
preliminary content which will go to the executable.  This is
preliminary is sense that there are holes to be filled by the
linker.  For linker it does not matter much if hole is part
of instruction or content of "variable" (I wrote variable in
quotes because if it goes to ROM it can not change, but for
linker it does not matter much).  Another part of object
file (relocation table) gives formulas which tell linker
how to compute values needed to fill holes.  I wrote
formulas because there is some calculation, but it
is rather simple.  Some values may be (absolute) constants
defined in other files.  Some are of form "start address
of module + offset" (offset inside module is known at
assembly time, start address is known only at link
time).  To make it more concrete look at part of
disassembly from example that I provided earlier:

from .o file:

00000200 <start>:
 200:   4a02            ldr     r2, [pc, #8]    ; (20c <start+0xc>)
 202:   6813            ldr     r3, [r2, #0]
 204:   3301            adds    r3, #1
 206:   6013            str     r3, [r2, #0]
 208:   e7fb            b.n     202 <start+0x2>
 20a:   bf00            nop
 20c:   00000000        andeq   r0, r0, r0

You see that addresses are just offsets from start of file,
instruction at offset 200 loads word at offset 20c.
Content of this word is not known at assembly time, so
objdump shows it as 0.

Now the same from .elf file:

08000200 <start>:
 8000200:       4a02            ldr     r2, [pc, #8]    ; (800020c <start+0xc>)
 8000202:       6813            ldr     r3, [r2, #0]
 8000204:       3301            adds    r3, #1
 8000206:       6013            str     r3, [r2, #0]
 8000208:       e7fb            b.n     8000202 <start+0x2>
 800020a:       bf00            nop
 800020c:       20000000        andcs   r0, r0, r0

Linker shifted object file to start of ROM, so now we have
instruction at absolute address 8000200 which loads word from
address 800020c.  Linker knows that this word is address of
variable c, which goes to RAM at 20000000, so linker changes
(fixes) content of constant at 800020c to 20000000.

Note that 411 starts with uninitialized RAM.  If you want
to initialize variables in RAM, you need to put initial
values in ROM and initialization code of your program
have to copy initial values to RAM.  If you use normal
embedded toolchain, your toolchain will provide starup
routine which responsible for initializing variables
and few other things expected by C code.  If you want
pure assembler you need to provide your own initialization
(my example was done in way which needs no extra
initialization, but it is doing nothing interesting,
just sits in infinite loop incrementing variable).

For debugging using gdb you can load data (or program)
to RAM (and linker supports this), but this depends
in debugging interface.  In context of classical OS,
operating system loads program to RAM.  Linker does
not care much if section goes to ROM or RAM.  Linker
simply puts specified sections in ELF executable
and fills holes according to rules (which may be
more complicated than exaples I gave, but not
very complicated).

--  
                              Waldek Hebisch

Site Timeline