2024-07-01 03:58 AM
Hello,
I'd like to create an output section called .cal_data capturing constants from a particular object file called const_params.o so I have created the following additional linker script entry based on the GNU syntax:
.cal_data :
{
const_params.o(.rodata)
} > FLASH
However, the linker (I'm using version 1.10.1) can't find the file:
ld.exe: cannot find const_params.o
Please can you help me find the correct syntax to achieve my objective.
Thank you very much.
2024-07-01 04:22 AM
Does the file exist?
Inspecting final .ELF perhaps look at objcopy, objdump, fromelf, etc.
Understand exactly what the compiler is outputting/generating..
2024-07-01 06:27 AM - edited 2024-07-01 07:25 AM
Thank you.
Yes the file exists albeit in sub folder.
This got me thinking that I need to qualify the object filename with a relative path:
.cal_data :
{
./ASW/ASW_Utils/const_params.o(.rodata)
} > FLASH
Now the linker completes its .elf output without error. However, the cal_data output section still does not appear.
Next, I noticed there's an apparent duplication of most input section names in a typical .ld file, e.g. .data and .data*
Following the hint, I added a wildcard to .rodata even though there's no basis for doing so since the target section name (.rodata) in unambiguous.
.cal_data :
{
./ASW/ASW_Utils/const_params.o(.rodata*)
} > FLASH
Fortunately this now triggers the correct result:
The implication is that only a wildcard for the input section is effective and indeed that is born out by experiment. For example, commenting out line 134 here does precisely nothing:
So this begs the question why the wildcard for the input section name is mandatory or, put another way, when would the line on 134 above be effective? I guess it's not critical, just curious.