TI中文支持网Part Number:AWR2944Other Parts Discussed in Thread: MATHLIB
The problems encountered when using the TI_Arm_Clang compiler option -flto are as follows. When using the AWR2944 chip, using -flto to compile and link will cause the following situations. I placed the link file of DSS_L3 in the cmd file, and some files will be damaged due to – The flto option is placed in the DSS_L2 address. My idea is to place it in the DSS_L3 location. The link file is always in DSS_L3. How to solve it?
Shine：
cheyrl wang 说： and some files will be damaged due
请问是在哪个例程上编译的？一些文件损坏具体是指什么？
,
cheyrl wang：
是我用-flto选项后，放在DSS_L3地址范围（代码段）的*.c函数放到了DSS_L2地址方位内（代码段）。
,
Shine：
已咨询e2e产品线工程师，请关注下面帖子的回复。https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1312931/awr2944-flto-option
,
Shine：
请以附件的形式发一下您的cmd文件核map文件，工程师需要查看一下，谢谢。Please put the linker command file and the linker map file in a zip, then attach that zip to your next post. Name one output section in the linker command file where this happens …
,
cheyrl wang：
/*—————————————————————————-*/
/* Linker Settings */
–retain="*(.intvecs)"/*—————————————————————————-*/
/* Section Configuration */
SECTIONS
{
systemHeap : {} > SBL_RESERVED_L2_RAM | MSS_L2
.demoSharedMem: { } >> DSS_L3
.l3ram: { } >> DSS_L3ctrklibs: > DSS_L3_TRACKER_MEM ALIGN(8)
{
bgu_*.oer5f(.tramp)
MathLib*.oer5f(.tramp)
TrafoLib*.oer5f(.tramp)
utilc*.oer5f(.tramp)
FeatLib.oer5f(.tramp)
ptToRbInfo.oer5f(.tramp)
RandLib.oer5f(.tramp)
RegLib_Linear.oer5f(.tramp)
buf_Wrapper.oer5f(.tramp)
pi_List.oer5f(.tramp)
pi_Element.oer5f(.tramp)
ptToFsInfo.oer5f(.tramp)
fs*.oer5f(.tramp)
objc*.oer5f(.tramp)
rb*.oer5f(.tramp)
Rb*.oer5f(.tramp)
egoPath*.oer5f(.tramp)
smf*.oer5f(.tramp)
ctrk*.oer5f(.tramp)
Ctrk*.oer5f(.tramp)
*_interface.oer5f(.tramp)
Tracker.oer5f(.tramp)bgu_*.oer5f(.text)
MathLib*.oer5f(.text)
TrafoLib*.oer5f(.text)
utilc*.oer5f(.text)
FeatLib.oer5f(.text)
ptToRbInfo.oer5f(.text)
RandLib.oer5f(.text)
RegLib_Linear.oer5f(.text)
buf_Wrapper.oer5f(.text)
pi_List.oer5f(.text)
pi_Element.oer5f(.text)
ptToFsInfo.oer5f(.text)
fs*.oer5f(.text)
objc*.oer5f(.text)
rb*.oer5f(.text)
Rb*.oer5f(.text)
egoPath*.oer5f(.text)
smf*.oer5f(.text)
ctrk*.oer5f(.text)
Ctrk*.oer5f(.text)
*_interface.oer5f(.text)
Tracker.oer5f(.text)bgu_*.oer5f(.bss)
MathLib*.oer5f(.bss)
TrafoLib*.oer5f(.bss)
utilc*.oer5f(.bss)
FeatLib.oer5f(.bss)
ptToRbInfo.oer5f(.bss)
RandLib.oer5f(.bss)
RegLib_Linear.oer5f(.bss)
buf_Wrapper.oer5f(.bss)
pi_List.oer5f(.bss)
pi_Element.oer5f(.bss)
ptToFsInfo.oer5f(.bss)
fs*.oer5f(.bss)
objc*.oer5f(.bss)
rb*.oer5f(.bss)
Rb*.oer5f(.bss)
egoPath*.oer5f(.bss)
smf*.oer5f(.bss)
ctrk*.oer5f(.bss)
Ctrk*.oer5f(.bss)
*_interface.oer5f(.bss)
Tracker.oer5f(.bss)bgu_*.oer5f(.rodata)
MathLib*.oer5f(.rodata)
TrafoLib*.oer5f(.rodata)
utilc*.oer5f(.rodata)
FeatLib.oer5f(.rodata)
ptToRbInfo.oer5f(.rodata)
RandLib.oer5f(.rodata)
RegLib_Linear.oer5f(.rodata)
buf_Wrapper.oer5f(.rodata)
pi_List.oer5f(.rodata)
pi_Element.oer5f(.rodata)
ptToFsInfo.oer5f(.rodata)
fs*.oer5f(.rodata)
objc*.oer5f(.rodata)
rb*.oer5f(.rodata)
Rb*.oer5f(.rodata)
egoPath*.oer5f(.rodata)
smf*.oer5f(.rodata)
ctrk*.oer5f(.rodata)
Ctrk*.oer5f(.rodata)
*_interface.oer5f(.rodata)
Tracker.oer5f(.rodata)bgu_*.oer5f(.data)
MathLib*.oer5f(.data)
TrafoLib*.oer5f(.data)
utilc*.oer5f(.data)
FeatLib.oer5f(.data)
ptToRbInfo.oer5f(.data)
RandLib.oer5f(.data)
RegLib_Linear.oer5f(.data)
buf_Wrapper.oer5f(.data)
pi_List.oer5f(.data)
pi_Element.oer5f(.data)
ptToFsInfo.oer5f(.data)
fs*.oer5f(.data)
objc*.oer5f(.data)
rb*.oer5f(.data)
Rb*.oer5f(.data)
egoPath*.oer5f(.data)
smf*.oer5f(.data)
ctrk*.oer5f(.data)
Ctrk*.oer5f(.data)
*_interface.oer5f(.data)
Tracker.oer5f(.data)
}}
,
Shine：
看到您已经在e2e帖子上回复工程师，请关注帖子的回复。
,
Shine：
请看下面e2e工程师最新的回复。工程师暂时还没有解决方法，他需要和其他工程师讨论一下，再给您答复。
The problem is that an input section specification like this one …
cheyrl wang said:
bgu_*.oer5f(.text)… presumes the linker sees some input sections named .text from files that are named bgu_*.oer5f. When you build with LTO, those input sections are not in a file named after the source file, but in a different file named lto29. Thus, this input section specification is effectively ignored.
I don't have a solution suggest. I'll discuss this with other members of my team and get back to you.
,
Shine：
请看下面e2e工程师最新的回复。
The only suggestion I have calls for a significant change in the linker command file. You can no longer rely on input section specifications that refer to the name of an object file. For instance …
cheyrl wang said:
bgu_*.oer5f(.text)… specifies all .text input sections found in files that begin with the name bgu_ and have the file extension .oer5f. You can no longer presume the linker sees those file names. You have to change to using only the names of the input sections, which are based on the names of the functions. For instance …
*(.text.name_of_function)
This specifies all the input sections named .text.name_of_function, without regard to the name of the file. There will be only one such input section, and it contains the function name_of_function.
Wild cards are accepted. If there are several functions with names that begin with common_prefix, you could write …
*(.text.common_prefix*)
I realize this is a significant change. But I cannot think of any other suggestion.
