Merge branch 'bugfix/fix_disassembler_interpreting_padding' into 'master'

(Xtensa) Build: add .xt.prop to the compiled ELF file

See merge request espressif/esp-idf!17268
This commit is contained in:
Omar Chebib 2022-07-05 13:48:42 +08:00
commit fca7be2ddb
6 changed files with 114 additions and 0 deletions

View File

@ -190,4 +190,23 @@ SECTIONS
_etext = .;
} > iram_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}

View File

@ -179,4 +179,23 @@ SECTIONS
_etext = .;
} > iram_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}

View File

@ -213,4 +213,23 @@ SECTIONS
_etext = .;
} > iram_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}

View File

@ -394,6 +394,25 @@ SECTIONS
. = ALIGN (8);
_heap_start = ABSOLUTE(.);
} > dram0_0_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}
ASSERT(((_iram_end - ORIGIN(iram0_0_seg)) <= LENGTH(iram0_0_seg)),

View File

@ -393,6 +393,25 @@ SECTIONS
. = ALIGN (8);
_heap_start = ABSOLUTE(.);
} > dram0_0_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}
ASSERT(((_iram_text_end - ORIGIN(iram0_0_seg)) <= LENGTH(iram0_0_seg)),

View File

@ -431,6 +431,25 @@ SECTIONS
. = ALIGN (8);
_heap_start = ABSOLUTE(.);
} > dram0_0_seg
/** This section will be used by the debugger and disassembler to get more information
* about raw data present in the code.
* Indeed, it may be required to add some padding at some points in the code
* in order to align a branch/jump destination on a particular bound.
* Padding these instructions will generate null bytes that shall be
* interpreted as data, and not code by the debugger or disassembler.
* This section will only be present in the ELF file, not in the final binary
* For more details, check GCC-212
*/
.xt.prop 0 :
{
KEEP (*(.xt.prop .gnu.linkonce.prop.*))
}
.xt.lit 0 :
{
KEEP (*(.xt.lit .gnu.linkonce.p.*))
}
}
ASSERT(((_iram_end - ORIGIN(iram0_0_seg)) <= LENGTH(iram0_0_seg)),