"Jeffi Edward.J" <j.jeffi@xxxxxxxxxxx> writes: > I do copying of .data from LMA to VMA as follows: > > memcpy(__data_start, __code_end, (__data_end - __data_start)); How did you declare those symbols in your C program? > Using --print-map option to linker, I generated map file of symbols. > I found the LMA of .data section in map file. > VMA of my .data is 0x3000000(as per above skeleton script). > Assume my LMA is 0x2000000 (__code_end). > I calculated the offset of that global variable with respect to LMA region. > I found in my LMA region itself, the global variables are not loaded > properly. i.e the global variable has the same junk value in LMA region. > > I found from map file that some additional section are generated in between > .data and .sdata. > .eh_frame, .jcr, .data.rel.local, .data.rel.ro.local, .data.rel. > > Are these sections needed? Is my LMA region corrupted my any other section? Those sections are needed. > On seeing the map file, I found that many additional section > .text._ZN6DArray***, .rela.text._ZN6DArray***, .rela.sdata.__ZTIS***, > .rela.rodata.__ZTIS***. Hmmm, C++. Do you see any .gnu.linkonce sections? If not, that is fine. If you do, you should mention them in your linker script. Unfortunately, I don't know what is going on. If the map file shows that the data sections are being handled properly, then you should not see junk in the LMA space. I don't know what could cause that. Ian
