Hi,
First of all, thank you for your response.
I will write some updates as well and please correct me if I´m saying something wrong.
the variable before was a 32 bit variable.
unsigned int Var1 = 0;
void function (unsigned int var2 )
{
Var1 |= var2;
}
and then I extended it :
unsigned long long Var1 = 0x0ULL;
void function (unsigned long long var2 )
{
Var1 |= var2;
}
Alternatively, the host can read/write the SPRAM by 8-, 16-, or 32-bit accesses in aligned addresses. (section 24.5.2.3 Parameter access, reference manual MPC5644ARM).
While the compiler automatically sets the type alignment to the largest alignment that can ever be used for any data type on the target machine for which you are compiling, which is our extended variable (8 bytes) boundary, that's why during the compilation, 4 padding bytes were required to align the start of the data segment to perform that 8 bytes alignment. (this is my understanding).
My conclusion:
The (initialized ) global data variables are almost by definition in the data section, since the alignment was 4 bytes in the data section, and the VA is 4 bytes aligned, on the other hand, the host can read any 32 bits variable, and everything worked fine. Please find attached a screenshot:
so the alignment was 4 boundaries.
You can see that the small data sections are gathered together in the program header so single-instruction offsets can access them all.
***************************************Then we extended that variable************************
When we extended that global variable, that small data segment split into two, and I found that the VA of data section changed. a 4 bytes padding has been performed by the compiler to ensure the new alignment (8 bytes boundaries).
The compiler automatically sets the type alignment to the largest it can ever use for any data type.
that's why that small data segment split into two:
and then , I tried to force that section to be 4 bytes aligned, to ensure that the access to that variable would be fine and no exception will occur, exactly like you said.
.data ALIGN (4): AT (NEXT_LOAD_ADDR)
{
__DATASTART = . ;
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
CONSTRUCTORS
} > int_sram
NEXT_LOAD_ADDR = NEXT_LOAD_ADDR + SIZEOF(.data);
and the bug has been fixed :
The size of the data section has also been increased by 4 bytes, 1413 - 4 (32 bits global variable) + 8 (64 bits global variable) = 1417 bytes
please correct me if I'm wrong, I have wrote everything to make sure we are on the same page and I'm not doing something wrong.
Thank you!
