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
gcc .data and .bss address space
Started by ●May 3, 2021
Reply by ●May 3, 20212021-05-03
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.elfThe 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
Reply by ●May 3, 20212021-05-03
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.
Reply by ●May 3, 20212021-05-03
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.
Reply by ●May 4, 20212021-05-04
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 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
Reply by ●May 4, 20212021-05-04
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.ldIf 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.
Reply by ●May 4, 20212021-05-04
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
Reply by ●May 4, 20212021-05-04
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 youBut 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.
Reply by ●May 4, 20212021-05-04
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.ldYou 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
Reply by ●May 4, 20212021-05-04
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 0x2002pThe 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
