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

[Alon Bar-Lev]

On Sat, 25 Oct 2025 at 05:00, H.J. Lu <hjl.tools@gmail.com> wrote:

> On Sat, Oct 25, 2025 at 9:34 AM Alon Bar-Lev <alon.barlev@gmail.com>
> wrote:
> >
> >
> >
> > On Sat, 25 Oct 2025 at 04:11, H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Sat, Oct 25, 2025 at 8:58 AM Alon Bar-Lev <alon.barlev@gmail.com>
> wrote:
> >> >
> >> >
> >> >
> >> > On Sat, 25 Oct 2025 at 03:55, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> >>
> >> >> On Sat, Oct 25, 2025 at 8:42 AM Alon Bar-Lev <alon.barlev@gmail.com>
> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Sat, 25 Oct 2025 at 02:21, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> >> >>
> >> >> >> On Sat, Oct 25, 2025 at 7:19 AM Alon Bar-Lev <
> alon.barlev@gmail.com> wrote:
> >> >> >> >
> >> >> >> > When using --input-target=binary, objcopy currently derives
> symbol names from
> >> >> >> > a mangled version of the input file name.  This approach can
> lead to
> >> >> >> > unpredictable results, as the generated symbols depend on the
> file path and
> >> >> >> > working directory.
> >> >> >> >
> >> >> >> > This patch introduces a new option:
> >> >> >> >
> >> >> >> >   --input-symbol <name>    Use <name> as the base symbol name
> for the input file
> >> >> >> >                            (default: derived from file name)
> >> >> >> >
> >> >> >> > It allows specifying an explicit symbol name, while preserving
> the existing
> >> >> >> > behavior as a fallback.
> >> >> >> >
> >> >> >> > Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>
> >> >> >> > ---
> >> >> >>
> >> >> >> Tests are missing.
> >> >> >>
> >> >> >> --
> >> >> >> H.J.
> >> >> >
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > I could not find reference to tests for the current implementation.
> >> >> > I added tests, I had to guess the target output, please let me
> know if there is a better method.
> >> >> >
> >> >> > Thanks,
> >> >> > Alon
> >> >>
> >> >> You are adding a new option.  You must be using it yourself.
> >> >> The outputs of the tests that you are adding should match your
> >> >> expectation.  Your test should cover all aspects of the new
> >> >> option.
> >> >>
> >> >
> >> > I do not follow... is there something wrong with the tests I added?
> >> > I would appreciate a review.
> >> >
> >> > Thanks,
> >> > Alon
> >>
> >> I could be wrong.   It looks like random outputs may pass your tests.
> >> You know exactly what output your option is generating.  You should
> check
> >> it against the actual output.
> >>
> >
> > I compared it to other tests patterns and it is at the same level,
> having `binary_*_symbol_*` is far from being random in this context.
> > Not sure what you mean actual output, I would appreciate an example of
> other test which does this per your expectation.
> >
> > Thanks,
>
> binary_*_symbol_* can match so many different things.
> Are all of them correct?
>
>
In this context of having ${symbol} explicitly mentioned as an argument or
derived from an input file which is also provided as a parameter.
It is far from being random and checks the functionality of the input
symbol argument addition.
Anyway, per your request I added an explicit validation, it will make it
harder to maintain if output format will change in future or in different
architecture which I cannot imagine a different behavior.

I would appreciate a review of the functional code before we invest any
more effort in the tests.

Thanks,
Alon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251025/57af0203/attachment-0001.htm>