The function now takes an argument for O_NONBLOCK. The first fix seems
straightforward. The second one is _probably_ fine, but I can't really
see any easy way to fix it because libbfd handles all its own IO. Maybe
we need to compile in both versions of read_build_id() and only call the
libbfd one on regular files? Or maybe in that specific use case it
doesn't care, the commit message for adding libbfd there mentioned Wine
PE binaries.

Signed-off-by: James Clark <james.clark@linaro.org>
---
James Clark (2):
      perf tests: Fix "PE file support" test build
      perf symbols: Fix HAVE_LIBBFD_BUILDID_SUPPORT build

 tools/perf/tests/pe-file-parsing.c | 4 ++--
 tools/perf/util/symbol-elf.c       | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)
---
base-commit: 07d9df80082b8d1f37e05658371b087cb6738770
change-id: 20250903-james-perf-read-build-id-fix-0ef6fbce0432

Best regards,
-- 
James Clark <james.clark@linaro.org>

On Wed, Sep 03, 2025 at 04:15:25PM +0100, James Clark wrote:
> The function now takes an argument for O_NONBLOCK. The first fix seems
> straightforward. The second one is _probably_ fine, but I can't really
> see any easy way to fix it because libbfd handles all its own IO. Maybe
> we need to compile in both versions of read_build_id() and only call the
> libbfd one on regular files? Or maybe in that specific use case it
> doesn't care, the commit message for adding libbfd there mentioned Wine
> PE binaries.

I noticed that yesterday and have this in the tmp.perf-tools-next
(thought that had sent to the list but didn't) branch:

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=tmp.perf-tools-next&id=4bfe653aa3fefd429671aa27413a1124fe65b9d1

But since this affects 6.17, even being opt-in, I think it should go
there together with other patches that Namhyung is collecting in
perf-tools.

Reviewed-by: Arnaldo Carvalho de Melo <acme@redhat.com>

- Arnaldo

> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> James Clark (2):
>       perf tests: Fix "PE file support" test build
>       perf symbols: Fix HAVE_LIBBFD_BUILDID_SUPPORT build
> 
>  tools/perf/tests/pe-file-parsing.c | 4 ++--
>  tools/perf/util/symbol-elf.c       | 3 ++-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> ---
> base-commit: 07d9df80082b8d1f37e05658371b087cb6738770
> change-id: 20250903-james-perf-read-build-id-fix-0ef6fbce0432
> 
> Best regards,
> -- 
> James Clark <james.clark@linaro.org>

Hello,

On Wed, Sep 03, 2025 at 12:34:15PM -0300, Arnaldo Carvalho de Melo wrote:
> On Wed, Sep 03, 2025 at 04:15:25PM +0100, James Clark wrote:
> > The function now takes an argument for O_NONBLOCK. The first fix seems
> > straightforward. The second one is _probably_ fine, but I can't really
> > see any easy way to fix it because libbfd handles all its own IO. Maybe
> > we need to compile in both versions of read_build_id() and only call the
> > libbfd one on regular files? Or maybe in that specific use case it
> > doesn't care, the commit message for adding libbfd there mentioned Wine
> > PE binaries.
> 
> I noticed that yesterday and have this in the tmp.perf-tools-next
> (thought that had sent to the list but didn't) branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=tmp.perf-tools-next&id=4bfe653aa3fefd429671aa27413a1124fe65b9d1
> 
> But since this affects 6.17, even being opt-in, I think it should go
> there together with other patches that Namhyung is collecting in
> perf-tools.
> 
> Reviewed-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Yep, sure.  I'll queue them to perf-tools.

Thanks,
Namhyung