From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/linux-tools: Exclude checking PE binaries from perf test
Date: Mon, 3 Oct 2022 21:15:36 +0200 [thread overview]
Message-ID: <20221003191536.GC30794@scaer> (raw)
In-Reply-To: <ee93a0b3-3743-3fbc-f34e-995178d429d8@gmail.com>
Florian, All,
On 2022-10-03 10:21 -0700, Florian Fainelli spake thusly:
> On 10/1/22 12:07, Yann E. MORIN wrote:
> >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.
[--SNIP--]
> >>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.
> >
> >Is that a publicly available toolchain?
> >Can you share the recipe how that toolchain was generated?
> Yes that will be done.
Great!
> >Do you have special, local changes in Buildroot to accomodate that toolchain? Will you submit those changes?
> Yes a few and yes we will, provided there is interest from the buildroot
> community to have support for a GNU-free and musl-libc based toolchain.
I am personally not interested in a "GNU-free" toolchain. However, I am
very much interested in an llvm-based toolchain.
Semantics, semantics! ;-)
> The
> approach we took for now is that we provide a GNU-compatible wrapper and set
> of executable names such that you build with clang/LLVM but you don't really
> need to know about it, except where it matters.
Yes, that sounds like a good approach.
> >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.
> Fair enough, how about we make sure the toolchain is available, can be
> re-created by anyone who desires so and then we submit the changes to
> buildroot that we have so you see the full picture?
Yes, that would be awesome!
As I said above: having support for using an llvm-based toolchain would
be very interesting!
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| 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
next prev parent reply other threads:[~2022-10-03 19:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 22:11 [Buildroot] [PATCH] package/linux-tools: Exclude checking PE binaries from perf test Florian Fainelli
2022-09-28 21:38 ` Thomas Petazzoni
2022-09-28 22:28 ` Florian Fainelli
2022-09-29 6:40 ` Thomas Petazzoni
2022-09-30 22:05 ` Florian Fainelli
2022-10-01 19:07 ` Yann E. MORIN
2022-10-03 17:21 ` Florian Fainelli
2022-10-03 19:15 ` Yann E. MORIN [this message]
2023-04-17 19:58 ` Yann E. MORIN
2023-04-19 0:27 ` Florian Fainelli
2023-04-23 10:40 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221003191536.GC30794@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@buildroot.org \
--cc=f.fainelli@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.