objcopy symbol name for binary input

[Jan Beulich]

On 23.10.2025 21:31, Alon Bar-Lev wrote:
> Hi,
> 
> I am sure this comes up now and then.
> 
> When copying binary data to ELF the symbol name is created using the full
> path of the input file. Using the full path is problematic when the build
> is using a temporary path or the build is using full path vs relative etc...
> 
> For example:
> 
> arm-none-eabi-objcopy \
>     --input-target binary \
>     --output-target elf32-littlearm \
>     --binary-architecture arm \
>     /tmp/a.txt /tmp/a.o
> 
> Creates the following symbols:
> 
> _binary__tmp_a_txt_start
> _binary__tmp_a_txt_end
> _binary__tmp_a_txt_size
> 
> The symbols are not fixed, since these depend on the location of the files
> or the current directory.
> 
> Yes, I can change directory to $(dirname) and use relative name, but why do
> we assume that the section name is the file name? Yes, I can copy the file
> to the requested section name then import, or change directory and
> use --redefine-sym to rename the known name to what application expects.
> 
> The best solution I've seen so far is to use /dev/stdin, for example:
> 
> arm-none-eabi-objcopy \
>     --input-target binary \
>     --output-target elf32-littlearm \
>     --binary-architecture arm \
>     --redefine-sym _binary__dev_stdin_start=_mydata_start \
>     --redefine-sym _binary__dev_stdin_end=_mydata_end \
>     --redefine-sym _binary__dev_stdin_size=_mydata_size \
>     /dev/stdin /tmp/a.o < /tmp/a.txt
> 
> This provides known symbols based on the static /dev/stdin and renames the
> symbols to what application expects regardless of what the filename is,
> where it is stored, if used relatively or absolute and what is the current
> directory.
> 
> However, using /dev/stdin is still a hack.
> 
> Will you consider accepting a patch to add a command-line argument to set
> the binary symbol similar to --prefix-symbols to add the symbol name or
> allow ignoring the directory part.

I see no reason why such a patch shouldn't be accepted (and actually be
welcome). Please go ahead.

Jan