日本語
Linker trashes initialized data at start-up?
Linker trashes initialized data at start-up?
Example (in Renesas e2 studio 2023-01 and GCC_VERSION 8.3.0.202405-GNURX):
- File > New > C/C++ Project > Select “GGCC for Renesas RX C/C++ Executable Project” > Next
- Name project > Browse Location > Next
- Keep tool chain (8.3.0.202405) > Select device “R5F52317AxLA” > Change to “E2 (RX)” HWD > Next
- Skip Smart Configurator > Next
- Next
- Next
- Finish
Project template created…
In main source file:
- Add some static volatile initiated variables just above the main function:
static volatile int Array[256] = {0x12345678};
static volatile unsigned int Probe = 0x11223344;
- Use them in main:
while(1) {
// TODO: add application code here
if(0x12345678 != Array[0]){return(-1);}
if(0x11223344 != Probe){return(-1);}
}
- Compile and run while it crashes before reaching main.
- Now remove the initiation part of the variables:
static volatile int Array[256];// = {0x12345678};
static volatile unsigned int Probe;// = 0x11223344;
- Compile and run successfully to main, although it then returns (-1) it is expected.
Any comments?
Best regards, Henrik
Hello,
Based on the description of the bug and the attached linker file, the cause seems to be a possible mismatch between the size and address range of the source and destination (FLASH/RAM) memory regions, probably due to alignment issues.
In order to get a better picture, please attach the map file (*.map extension) and the start.S file (or it’s equivalent), where the flash to ram initialization happens.
If you wish to share the file(s) privately, please open up a support ticket and attach them there.
The Open Source Tools Team
-
Hello : )
All is good until .sdata extends some magic border.
The initialization code is correct, however when it fails, .idata is put into RAM not in ROM if you look into the .mot file. Actually it rather looks like neither AT() behaves, putting the lot into RAM.This is after increasing the .sdata with one byte extra, no other changes.
/Henrik
-
Hello,
We would like to remind you that we cannot help you if you do not attach the requested files (map, start.S) or a minimally-reproducible example.
If you wish to share the file(s) privately, please open up a support ticket and attach them there.
Best regards,
The Open Source Tools Team -
Hi there : )
When I removed the two AT() from the linker script the resulting .mot file did not change compared to the bad one. There may be some problems with ld.exe…
Anyway, here are some snipplets:
Source code regarding .sbss .sdata initialization:
– – – – – – – – – – – – – – – – – – – – – – – – –
static int InitiateSmallData(void)
{
register int R1 __asm__ (“r1”); // SMOVF/SSTR.L target address and return register
register int R2 __asm__ (“r2”); // SMOVF/SSTR.L source address/data register
register int R3 __asm__ (“r3”); // SMOVF/SSTR.L 32-bit/8-bit word count register
__asm__ __volatile__
(
// zero initiate GP->_sbss
“MOV %5,%1\n\t” // R1->_sbss
“TST #3,%1\n\t” // PSW(SZ) = 0b11 & &_sbss
“BNZ LDataBad\n\t” // non-even alignment -> FAIL
“MOV #0,%2\n\t” // R2 = 0x00000000
“MOV %6,%3\n\t” // R3->_sbss_next
“TST #3,%3\n\t” // PSW(SZ) = 0b11 & &_sbss_next;
“BNZ LDataBad\n\t” // non-even alignment -> FAIL
“SUB %1,%3\n\t” // R3 = sizeof(_sbss)
“SHLR #2,%3\n\t” // R3 /= sizeof(int)
“SSTR.L \n\t” // memset(_sbss,0,sizeof(_sbss))
// initiate GP->_sdata
“MOV %7,%1\n\t” // R1->_sdata
“MOV %9,%2\n\t” // R2->_idata
“MOV %8,%3\n\t” // R3->_sdata_next
“SUB %1,%3\n\t” // R3 = sizeof(_sdata)
“SMOVF \n\t” // memcpy(_sdata,_idata,sizeof(_sdata))
// initiate GP (all possible gp registers)
“MOV %4,r13\n\t” // R13->_gp – gcc view (when int-register plus pid is 0)
“MOV %5,r12\n\t” // r12->_sbss – lkr view (when int-register plus pid is 1)
“CMP r13,r12\n\t” // PSW(OSZC) = lkr – gcc
“BNE LDataBad\n\t” // different view -> FAIL
“MOV r13,r11\n\t” // r11->_sbss
“MOV r13,r10\n\t” // r10->_sbss
“MOV r13,r9\n\t” // r9->_sbss
“MOV r13,r8\n\t” // r8->_sbss
“LDataGood:\n\t”
“MOV #0,%1\n\t” // R1 = 0 (OK)
“LDataBad:\n\t”
// R1 always non-zero
:”=r”(R1),”=r”(R1),”=r”(R2),”=r”(R3)
:”i”(&_gp) // %4
,”i”(&_sbss) // %5
,”i”(&_sbss_next) // %6
,”i”(&_sdata) // %7
,”i”(&_sdata_next) // %8
,”i”(&_idata) // %9
:”memory”
);
return(0);
}Corresponding e2-studio disassembly (in-line):
– – – – – – – – – – – – – – – – – – – – – – –
fffa2f0a: mov.l #0x1800, r1
fffa2f10: tst #3, r1
fffa2f14: bne.b 0xfffa2f5a
fffa2f16: mov.l #0, r2
fffa2f18: mov.l #0x5da0, r3
fffa2f1e: tst #3, r3
fffa2f22: bne.b 0xfffa2f5a
fffa2f24: sub r1, r3
fffa2f26: shlr #2, r3
fffa2f28: sstr.l
fffa2f2a: mov.l #0x5da0, r1
fffa2f30: mov.l #0xfffac530, r2
fffa2f36: mov.l #0x7e04, r3
fffa2f3c: sub r1, r3
fffa2f3e: smovf
fffa2f40: mov.l #0x1800, r13
fffa2f46: mov.l #0x1800, r12
fffa2f4c: cmp r13, r12
fffa2f4e: bne.b 0xfffa2f5a
fffa2f50: mov.l r13, r11
fffa2f52: mov.l r13, r10
fffa2f54: mov.l r13, r9
fffa2f56: mov.l r13, r8
LDataGood:
fffa2f58: mov.l #0, r1
387 __asm__ __volatile__
LDataBad:Excerpts from the map file:
– – – – – – – – – – – – – –
…
.sbss 0x0000000000001800 0x45a0 load address 0x00000000fffb0000
0x0000000000001800 . = ALIGN (0x4)
0x0000000000001800 __gp = .
0x0000000000001800 __sbss = .
*(.sbss.*)
…
*(B)
…
*(B_1)
…
*(B_2)
…
0x0000000000005da0 . = ALIGN (0x4)
0x0000000000005da0 __sbss_next = ..sdata 0x0000000000005da0 0x2064 load address 0x00000000fffac530
0x0000000000005da0 . = ALIGN (0x4)
0x0000000000005da0 __sdata = .
*(.sdata.*)
…
*(D)
…
*(D_1)
…
*(D_2)
…
0x0000000000007e04 . = ALIGN (0x4)
0x0000000000007e04 __sdata_next = .
…
.idata 0x00000000fffac530 0x2064
0x00000000fffac530 . = ALIGN (0x4)
0x00000000fffac530 __idata = .
0x00000000fffae594 . = (. + SIZEOF (.sdata))
*fill* 0x00000000fffac530 0x2064
…I hope you find something useful there…
In the mean time I just adjust the .sdata section to get by.
BTW, I don’t know how you attach files in here…
Cheers
/Henrik -
Maybe I found a work around?
I changed the order of the linker script by putting the .sdata before .sbss (see post number 3).
All related references are moved accordingly.Don’t know why but it works.
Maybe I’m walking on egg shells?
/Henrik -
Hello,
The linker script documentation (https://sourceware.org/binutils/docs/ld/Location-Counter.html) mentions: “Note: . actually refers to the byte offset from the start of the current containing object.
Normally this is the SECTIONS statement, whose start address is 0, hence . can be used as an absolute address. If . is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address.”According to the provided linkerscript _idata is declared inside .idata, resulting in a relative offset which in this case will be 0 since .idata is has no input sections.
You need to declare _idata outside the .idata section descriptor to make sure it’s an absolute address.__
Best regards,
The Open Source Tools Team -
Hello there : )
I did what the manual and you told me but the output remains the same.
This was not entirely unexpected!? due to this works until the smal data exceeds some magic size (lot less than set by -msmall-data).
Then why does it work (as far as I can see) when i swap the order of .sbss and .data (keeping the __gp first)?
The AT command just semes to stop work when thiis happens…
Okay, I’ve got one *work around* that still works so I’ll stick to it.
However, if you catch the real culprit I’m all ears.
Keep cool = )
/Henrik -
Hello again : )
*edit* sometimes early mornings get the best of you…
“while(1)” is needed, and no, the problem is still there…
*edit end**edit 2*
I changed the test towards something the compiler coud not *resolve* like “while(solmething volatile that never is 0)” and this time it works, with the backgroud checks active.
*edit 2 end*This work-around did eventually break too…
The AT feature in the link script is ignored, as before.
All the backed-up data and code is put in RAM instead of FLASH.By luck I noticed it happened with a slight change in main background.loop. “for(;;)”
I changed it to “while(0)”, nothing else and it works again.Therefore this behavior may probably be a combination of the compiler and the linker.
What do you think?
/Henrik -
Hello there : )
I think I’ve finally got it!?
Don’t really know why c-source changes may trigger this *AT* omission but a decent linker script fix works:
Originally the small sections were like:
.sbss : { __gp = .; } > RAM
.sdata : AT() { } > RAMThis went sour on larger .sdata content with the effect the AT command semed ignored and fixed by reordering:
.sdata : AT() { __gp = .; } > RAM
.sbss : { } > RAMLater on even this fix triggered this phenomena.
By forcing the background loop test in main:
from for(;;){ } to
while(SYSTEM.MSTPCRA.BIT.MSTPA19){ }
All were fine again.Then I tried to tell the linker that really is *buddies*:
.sdata : AT() { __gp = .; } > RAM
.sbss . : { } > RAM
A small change that in some way makes sense that works, even with a for-ever loop = )I can imagine there is either a lack of understanding, unclear documentation or a bug behind this.
Maybe other find this informative…
Cheers
/Henrik
Hello,
Thank you for reaching out to us!
Unfortunately we are not able to reproduce the issue.
In order to aid our investigation, please attach the full-built e2 Studio project for both of
the mentioned cases. You may also share the code privately with us by opening a dedicated support ticket, where you can attach it.
__
Best regards,
The Open Source Tools Team
Hello again : )
This is odd, yesterday I created that sample project twice to ensure it really happened, and it did. Today it will not happen. Unfortunately, I deleted all the files in between as I easily replicated the problem (back then).
As I recall, the problem was when the “jsr _HardwareSetup” vas taken, it jumped somewhere in the Exception table (just somewhere ahead) with the fatal rte.
The real project amounts to nearly 2000 source files and still have this problem. What I can see, the initialized data transfers from flash works incorrectly. the size of .sdata is 8 bytes larger than the .idata and therefore it mis-alignes somewhere the near end.
This happens only when .sdata ends on an even boundary, like 0x6000 so my work around is to put another int (dummy) in the .sdata section when it happens.
Now, I suspects our linker script may be the culprit?
Maybe someone with better knowledge can tell:
8X – – – –
SECTIONS /* * * Random Access Memory * * */
{
/* * * unique input sections first * * */
.kernel (NOLOAD) : {*(.coredata)} > RAM
.system (NOLOAD) : {*(.system)} > RAM
.scode : AT(__icode) {. = ALIGN(4); __scode = .; *(.scode) . = ALIGN(4); __scode_next = .;} > RAM
.ustack (NOLOAD) : {. = ALIGN(SYS_RANGE); *(.ustack)} > RAM
.istack (NOLOAD) : {. = ALIGN(4); *(.istack)} > RAM
/* * * zero-initiated data sections then * * */
.sbss : {. = ALIGN(4); __gp = .; __sbss = .; *(.sbss.*) *(B) *(B_1) *(B_2) . = ALIGN(4); __sbss_next = .;} > RAM
/* * * initiated data sections then * * */
.sdata : AT(__idata) {. = ALIGN(4); __sdata = .; *(.sdata.*) *(D) *(D_1) *(D_2) . = ALIGN(4); __sdata_next = .;} > RAM
/* * * versatile input sections last * * */
.bss : {. = ALIGN(4); *(.bss) *(.bss.*) *(COMMON)} > RAM
}
SECTIONS /* * * Program Flash Memory * * */
{
/* * * unique input sections first * * */
.cfm : {*(.rodata.cfm)} > APPL
.stall : {*(.text.halt)} > APPL
.reset : {*(.text.reset)} > APPL
/* * * versatile input sections then * * */
.text : {*(.text.*) *(C) *(C_1) *(C_2) *(P)} > APPL
.rodata : {*(.rodata.*)} > APPL
/* * * initiation data section last * * */
.idata : {. = ALIGN(4); __idata = .; . += SIZEOF(.sdata);} > APPL
.icode : {. = ALIGN(4); __icode = .; . += SIZEOF(.scode);} > APPL
}
– – – – X8
Note: the RAM/APPL is defined in a device specific ld-file.
Hopefully this was not too much of a wall of text…
Thank you for your time
/Hen