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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3.5.21 17.35, Ed Lee wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

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

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

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

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

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

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

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

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

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

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

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.

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.

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.

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

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

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

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?

Punch is a custom program to reduce the holely file by mmu instructions from the project. This still require an intermediate 500M bytes file to generate 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 instructions.

mmu instructions:

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

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4.5.21 18.14, Ed Lee wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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

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

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

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.

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

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

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

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.

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.

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.

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

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

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

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?

Punch is a custom program to reduce the holely file by mmu instructions from the project. This still require an intermediate 500M bytes file to generate 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 instructions.

mmu instructions:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4.5.21 18.14, Ed Lee wrote:

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.

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

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

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

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

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

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?

Punch is a custom program to reduce the holely file by mmu instructions from the project. This still require an intermediate 500M bytes file to generate 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 instructions.

mmu instructions:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Lee <edward.ming.lee@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: >>>>> On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

r2 = 550 (aprox)

.L2:
ldr r3, [r2]

r3 = c

adds r3, r3, #1

r3 = d

str r3, [r2]

store d to memory location 550

Segmentation violation. Can't write to ROM.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:

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

In general (since forever) you can't go wrong with MORE sections.
This makes the layout of the code visible to the link/load phase.

I put the *ROM* copy of vectors in one section and the *RAM*
copy in another (as the code will switch to the RAM copy once
the ROM image has been verified and RAM initialized, program
loaded, etc.).

Likewise, the boot loader, BIST, etc.

This lets you juggle where things should "fit" in the final image
instead of having to examine the code, itself, to determine the
structure. The tools are already there; let them do the work.

[It also makes it easier to reuse "sections" from one project
to the next]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: >>>>> On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

r2 = 550 (aprox)

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Lee <edward.ming.lee@gmail.com> wrote:

On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote: >>>>> On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

r2 = 550 (aprox)

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

.L2:
ldr r3, [r2]

r3 = c

adds r3, r3, #1

r3 = d

str r3, [r2]

store d to memory location 550

Segmentation violation. Can't write to ROM.

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

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

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Don Y <blockedofcourse@foo.invalid> wrote:

On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:

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

In general (since forever) you can't go wrong with MORE sections.
This makes the layout of the code visible to the link/load phase.

I put the *ROM* copy of vectors in one section and the *RAM*
copy in another (as the code will switch to the RAM copy once
the ROM image has been verified and RAM initialized, program
loaded, etc.).

Likewise, the boot loader, BIST, etc.

You probably imagine something more complicated than STM32F411.

This lets you juggle where things should "fit" in the final image
instead of having to examine the code, itself, to determine the
structure. The tools are already there; let them do the work.

[It also makes it easier to reuse "sections" from one project
to the next]

The example is a toy which IMO fulfils its purpose. As I wrote
I have vectors as subsection, in linker script I can put it
where I want it, simply to the moment it was most convenient
to put it in .text. With my setup I can link .text so that
it goes to RAM, which is convenient for debugging small programs
or to ROM (usual setup). Script provided by Tauno Voipio
creates overlapped sections in final executable, I do not
know why. I can imagine use of overlapped sections in RAM,
but what they buy in ROM?

Personaly, I am trying to avoid unnecessary complexity.
Currently linker scripts give me enough possibilities
to rearrange code, so I felt no need to additionally
juggle sections in executable (that would be different
if an OS was present, but I am talking here about
programs running on bare hardware).

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/4/2021 4:14 PM, antispam@math.uni.wroc.pl wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:

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

In general (since forever) you can't go wrong with MORE sections.
This makes the layout of the code visible to the link/load phase.

I put the *ROM* copy of vectors in one section and the *RAM*
copy in another (as the code will switch to the RAM copy once
the ROM image has been verified and RAM initialized, program
loaded, etc.).

Likewise, the boot loader, BIST, etc.

You probably imagine something more complicated than STM32F411.

I try to solve similar problems in very similar ways. So, I
don't have to explain why I did "something different" in one
case (but not another).

This lets you juggle where things should "fit" in the final image
instead of having to examine the code, itself, to determine the
structure. The tools are already there; let them do the work.

[It also makes it easier to reuse "sections" from one project
to the next]

The example is a toy which IMO fulfils its purpose. As I wrote
I have vectors as subsection, in linker script I can put it
where I want it, simply to the moment it was most convenient
to put it in .text. With my setup I can link .text so that
it goes to RAM, which is convenient for debugging small programs
or to ROM (usual setup). Script provided by Tauno Voipio
creates overlapped sections in final executable, I do not
know why. I can imagine use of overlapped sections in RAM,
but what they buy in ROM?

I've not examined the post so can't comment on specifics.

As to overlaying "ROM", I've done so (ages ago) in the
era of bank-switched hardware -- switching ROM *out* of
an address space after POST so those reserved locations
(common in smaller MPUs) could be more effectively used
(out of RAM).

Likewise, swapping banks of RAM into portions of the
logical address space (to support independent stacks
and heaps for many threads).

You can also overlay read and write accesses to portions
of an address space (e.g., read an address yields one
datum while writing drives another -- most common in
mapped I/O)

<shrug> Dunno.

But, in each case, doing it in the code makes the code
more brittle; if the address map changes, then the *code*
has to change. And, the change has to be ferreted out
(instead of exposed in a simple script).

Personaly, I am trying to avoid unnecessary complexity.
Currently linker scripts give me enough possibilities
to rearrange code, so I felt no need to additionally
juggle sections in executable (that would be different
if an OS was present, but I am talking here about
programs running on bare hardware).

Every project I've built runs on bare iron. Even my
current project has to install the POST/BIST/loader/etc.
on bare iron *before* it can load (over the wire) the
actual OS and, then, the application.

On reset, I have to ensure the initial PC, etc. is
available (from "ROM"). A small/tight checksum
routine to verify the next stage of boot is intact.
Then, code to verify the hardware can be used *by* that
next stage of the boot (i.e., do I have any functional
RAM?)

Eventually, invoking specific test routines for *this*
hardware (different set of I/Os than other devices running
the same boot code) by probing a portion of the address
space into which those ROM-based routines would exist.
All that before beginning to set up the environment and
network stack to download the OS image.

Plus, a "safe" copy of the boot loader so I can
reflash without fear of making a brick.

Having a "rich" structure/methodology to call upon for juggling
these various "boxes" makes it easier to add as new requirements
come along. And, exposes these details at a higher level
(so the Next Guy isn't scratching his head wondering
why "this is here" and "that is there").

[I.e., it's easier to document a script than it is to
embed lots of notes in a variety of different files and
HOPING the Next Guy can find all of them!]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Lee <edward.ming.lee@gmail.com> wrote:

On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:

On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

r2 = 550 (aprox)

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

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 4, 2021 at 5:21:46 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:

Ed Lee <edward....@gmail.com> wrote:

On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:

On 4.5.21 16.32, Ed Lee wrote:

On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:

On 3.5.2021 22:14 PM, Ed Lee wrote:

On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote: >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:

On 3.5.21 17.35, Ed Lee wrote:

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

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.

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

Looks OK

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

Given correct main.o shoud be OK.

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

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

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

r2 = 550 (aprox)

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

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

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/4/2021 6:06 PM, Ed Lee wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:

On 5/4/2021 6:06 PM, Ed Lee wrote:

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

"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 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 case, if the assembler is using
the content of the variable pointing to the data variable's address, it would remain in the rom space.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/4/2021 6:33 PM, Ed Lee wrote:

On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:

On 5/4/2021 6:06 PM, Ed Lee wrote:

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

"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 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 case, if the assembler is using the content of the variable pointing to the data variable's address, it would remain in the rom space.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Lee <edward.ming.lee@gmail.com> wrote:

On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:

On 5/4/2021 6:06 PM, Ed Lee wrote:

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

"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 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 case, if the assembler is

using the content of the variable pointing to the data variable's address, it would remain in the rom space.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)