default linker script fails to support RESTART button for MDB

[beihuang00]

trafficstars

Issue Summary

• Type: Bug
• Category: Example
• Priority: High
• Release Version: Specified version such as 2019.06

---

Bug

Development Environment

• HOST OS all OS

• TOOLCHAIN MWDT R-2020.12

• BOARD HSDK, EMSDP

• ARC CORE HS38, EM11D_DFSS

Bug Description

The default linker script for mw have a relocate 'AT >' for .data section: at line 81 of embarc_osp-2019.06\board\linker_template_mw.ld GROUP : { .data ALIGN(8): { _f_data = .; _f_sdata = .; *(.sdata) *(.sbss) _e_sdata = .; *(TYPE data) } .tls ALIGN(8): { *(.tls*) _e_data = .; } } > REGION_RAM AT > REGION_ROM This results in that Metaware Linker trate .data section as <R> read-only.

Problem is that, for HSDK and EMSDP board, .data section is relocated to the same memory space: } > REGION_EXT_RAM AT > REGION_EXT_RAM This causes problem for RESTART button in Metaware Debugger. If the content for .data section was modified in last execution, when users click RESTART button to rerun the program, Debugger re-load the elf and do elf verify check for some memory address spot. The <R> flagged .data section will not be re-loaded by Debugger during the RESTART procedure, and the modified .data section content leads to elf verify check fail - users not able to do RESTART.

This issue can be easily reproduced by example embarc_osp-2019.06\example\baremetal\arc_feature\cache on HSDK or EMSDP.

---

Enhancement

fix the default linker

---

Question

What is the design purpose of EMBARC OSP for making .data section to be relocated by default? Is it can be fixed simply by removing the relocation 'AT >'?

[beihuang00]

Bug found in a presales evaluation project. Hope to be fixed ASAP to get more chance to win this customer.

[beihuang00]

[YuguoWH]

Hi @beihuang00 , thanks for reporting this issue. I'm fixing the issue in 748992d (tested this commit on HSDK (hs38) and EMSK (em7d) ) And for the question you raised, I suppose that was designed for XIP (execute in place) devices, which is not the case for our HSDK, EMSK, etc.