Pass -B to objcopy binary symbol test

[Alon Bar-Lev]

On Mon, 3 Nov 2025 at 02:19, Alan Modra <amodra@gmail.com> wrote:

> On Mon, Nov 03, 2025 at 01:56:50AM +0200, Alon Bar-Lev wrote:
> > On Mon, 3 Nov 2025 at 01:38, Maciej W. Rozycki <macro@orcam.me.uk>
> wrote:
> >
> > > On Fri, 31 Oct 2025, Alan Modra wrote:
> > >
> > > > objcopy -I binary -O some_coff_target does not currently work without
> > > > choosing a valid arch with -B.  This used to be the case for ELF
> > > > targets too, until commit 6765ee1825d9.
> > >
> > >  FWIW this test still fails for numerous targets:
> > >
> > > aarch64-darwin  +FAIL: binary symbol (implicit)
> > > aarch64-darwin  +FAIL: binary symbol (explicit)
> > > arm-darwin  +FAIL: binary symbol (implicit)
> > > arm-darwin  +FAIL: binary symbol (explicit)
> > > hppa-hp-hpux10  +FAIL: binary symbol (implicit)
> > > hppa-hp-hpux10  +FAIL: binary symbol (explicit)
> > > i386-darwin  +FAIL: binary symbol (implicit)
> > > i386-darwin  +FAIL: binary symbol (explicit)
> > > kvx-elf  +FAIL: binary symbol (implicit)
> > > kvx-elf  +FAIL: binary symbol (explicit)
> > > kvx-linux  +FAIL: binary symbol (implicit)
> > > kvx-linux  +FAIL: binary symbol (explicit)
> > > powerpc-darwin  +FAIL: binary symbol (implicit)
> > > powerpc-darwin  +FAIL: binary symbol (explicit)
> > > x86_64-darwin  +FAIL: binary symbol (implicit)
> > > x86_64-darwin  +FAIL: binary symbol (explicit)
>
> Yes, I think all of these fails are due to target bugs in handling
> foreign object file symbols.  ie. the new test exposed old problems.
>
> > I see that the template `^[0-9a-fA-F]+?[ ]+[TtDdA] ([0-9a-zA-Z_]+` does
> not
> > support the `U`.
>
> Nor should it.  The symbols are not undefined.
>
> > Can you please describe how you run this CI, I will try to fix
> everything.
>
> configure \
> --disable-gdb --disable-gdbserver --disable-sim --disable-readline \
> --disable-libbacktrace --disable-libdecnumber --disable-gprofng \
> --target=aarch64-darwin
> make
> make check
>
> And similarly for the other targets.
>
> --
> Alan Modra
>

Hi,

I reviewed the test code as much as I could understand, I would need
assistance in understanding what is the expected solution.

The patch of introducing --input-target=binary added a unit test to check
the binary target symbol functionality which was not implemented
before per H.J. Lu suggestion, maybe it was a mistake to introduce new test
functionality in the same patch, test functionality as any functionality
is a new functionality while the patch was a minor modification of existing
functionality.

In the test, the detection of target and architecture is performed using
the objcopy --info output, selecting the first entry, maybe this behavior is
incorrect as well. I found that if I do not pass parameters to istarget I
get the current target, so it can be used instead of getting it out of the
output.
However, I could not find a way to retrieve the architecture.
I found a single example in ld/testsuite/ld-elf/linux-x86.exp that uses
architecture, but it derived it hard-coded from the target, and we do not
want to do that.

Maciej, thank you for the hint, I converted the test to this framework,
however:
* Can I trust the symbols order in nm -a output?
* Can I avoid running as on the source file? As far as I have tested and
reviewed the source assembly is always running.

In order to automate the coverage, I created Makefile.ci [attached] which
may be handy to have this in the tree, this builds and checks a list of
targets,
I wonder how to construct a good coverage of supported targets, I could not
find how to obtain the information from any trusted source.

Assuming I have a solution of getting the target and architecture
properly... and I have a good coverage in Makefile.ci...

I would like to understand what we do with the unknown symbols that we get
in some architecture, what is the correct course of action?
* Fix the objcopy implementation
* Accept the unknown symbols as valid in the test
* Skip the test on these targets
* Other?

Regards,
Alon Bar-Lev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20251107/c0677784/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.ci
Type: application/octet-stream
Size: 2625 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20251107/c0677784/attachment.obj>