Re: [Buildroot] [PATCH] package/linux-tools: Exclude checking PE binaries from perf test

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Florian, All,

On 2022-09-28 15:28 -0700, Florian Fainelli spake thusly:
> On 9/28/22 14:38, Thomas Petazzoni wrote:
> >On Tue, 27 Sep 2022 15:11:33 -0700
> >Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>Since upstream Linux commit ed21d6d7c48e6e96c2d617e304a7ebfbd17b1807
> >>("perf tests: Add test for PE binary format support") present in >=
> >>v5.10 there is an unconditional installation of PE binaries which will
> >>be rejected by the check-bin-arch script.
> >>
> >>Make sure that these binaries are excluded from being checked to allow
> >>the installation of the perf tests.
> >>
> >>Fixes: 6fcdaa4c5096 ("package/linux-tools: Allow installation of perf scripts")
> >>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> >Thanks for the patch! Before merging it, I'd like to understand a
> >little bit more how readelf behaves for these PE files. Indeed in
> >check-bin-arch, we are doing:
> >
> >         arch=$(LC_ALL=C ${readelf} -h "${TARGET_DIR}/${f}" 2>&1 | \
> >                        sed -r -e '/^  Machine: +(.+)/!d; s//\1/;' | head -1)
> >
> >         # If no architecture found, assume it was not an ELF file
> >         if test "${arch}" = "" ; then
> >                 continue
> >         fi
> >
> >for a PE file, I would expect readelf to badly fail, and therefore
> >${arch} to be empty, and the file simply ignored.
> >
> >What is the behavior/output of readelf on these PE files?
> 
> If I use my host system readelf which is packaged from
> binutils-x86-64-linux-gnu, I get no output and all is well, however when
> check-bin-arch is called and it uses $(TARGET_READELF), I do get:
> 
> ./host/bin/aarch64-linux-readelf -h
> build/linux-custom/tools/perf/tests/pe-file.exe | sed -r -e '/^ Machine:
> +(.+)/!d; s//\1/;' | head -1
> IMAGE_FILE_MACHINE_AMD64 (0x8664)
> 
> which is what prompted me to issue this patch in the first place.
> 
> I should mention that the readelf binary in this case is the LLVM Object
> Reader and it does support PE/COFF which is probably why it even remotely
> attempts to parse the file.

OK, but isn't that flawed? It is named 'readelf', so I would expect it
to not report on non-ELF files, at least by default (i.e. unless a
specific option flag is passed).

If a readelf tool does not behave like a readelf tool should behave,
isn't that a bug in that specific readelf tool to begin with?

Otherwise, it is very intriguing how you managed to have a toolchain
without gcc et al, be usable for Buildroot that only knows about the GNU
ecosystem.

Is that a publicly available toolchain? Can you share the recipe how
that toolchain was generated? Do you have special, local changes in
Buildroot to accomodate that toolchain? Will you submit those changes?

That would allow adding more testing to avoid such issue in the future.
Otherwise, I am not fan of adding such exclusion for private cases that
we can not (easily) reproduce, as those cases are not supported.

Regards,
Yann E. MORIN.

> -- 
> Florian
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot