[PATCH] objcopy: add option to specify custom symbol name for binary input

[Alon Bar-Lev]

On Mon, 27 Oct 2025 at 08:47, Alan Modra <amodra@gmail.com> wrote:

> Some comments on the patch.
>
> I don't see the need for a struct bfd change.  binary.c is always
> compiled in to libbfd, so setting a variable defined in binary.c
> should be OK.  (This sort of thing is already done for srec and
> verilog.)
>
> It seems to me that it might be more useful if the objcopy option set
> the entire binary symbol prefix, and the option be called
> --binary-symbol-prefix.
>
> You failed to change the symbol string memory allocation.
>
> --
> Alan Modra
>

Hi Alan,

On Mon, 27 Oct 2025 at 08:47, Alan Modra <amodra@gmail.com> wrote:

> Some comments on the patch.
>
> I don't see the need for a struct bfd change.  binary.c is always
> compiled in to libbfd, so setting a variable defined in binary.c
> should be OK.  (This sort of thing is already done for srec and
> verilog.)
>
>
Thank you for your comments.

I tried hard to understand what is "a variable defined in binary.c", I see
that all functions are getting the bfd as a context. I do not see any
global variables being used.the bfd_target is not specific to binary so I
guess you do not mean modifying it. Can you please refer me to a similar
variable that I can use?



> It seems to me that it might be more useful if the objcopy option set
> the entire binary symbol prefix, and the option be called
> --binary-symbol-prefix.
>

This is interesting... as if you use the following:

$ ./binutils/objcopy --input-target binary --output-target elf64-x86-64
--prefix-symbols aaaa /tmp/a.bin /tmp/a.o  && nm -a /tmp/a.o
0000000000000200 D aaaa_binary__tmp_a_bin_end
0000000000000200 A aaaa_binary__tmp_a_bin_size
0000000000000000 D aaaa_binary__tmp_a_bin_start

We already have a solution if we strip the addition of the
"_binary_${file}" and settle with the prefix provided.
I followed the logic of --prefix-symbols and it is very intrusive to the
flow, and is not visible to binary.c as far as I could see to keep backward
compatibility.

I modified the argument per your suggestion.



> You failed to change the symbol string memory allocation.


Oh, right, thank you!

I am sending a new revision of my previous implementation, I understand
better what you suggest by not modifying the bfd.

Regards,
Alon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251027/b2aeebab/attachment.htm>