Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230417122943.2155502-1-anders.roxell@linaro.org>
 <20230417122943.2155502-2-anders.roxell@linaro.org> <CAP-5=fWUevSnyn5MtVO1p6cEVE8MvBTq4Qgth7RcPYueRERQKA@mail.gmail.com>
 <d940f802-8aab-140d-7a87-9cf0b3a8ac9f@isovalent.com>
In-Reply-To: <d940f802-8aab-140d-7a87-9cf0b3a8ac9f@isovalent.com>
From:   Ian Rogers <irogers@google.com>
Date:   Tue, 18 Apr 2023 11:04:35 -0700
Message-ID: <CAP-5=fVh=zNuwcQM++KFxt6ETv-Z6GpY9pWDQ=RbvnuSGUhT8g@mail.gmail.com>
Subject: Re: [backport PATCH 1/2] tools perf: Fix compilation error with new binutils
To:     Quentin Monnet <quentin@isovalent.com>
Cc:     Anders Roxell <anders.roxell@linaro.org>, stable@vger.kernel.org,
        acme@redhat.com, andres@anarazel.de, linux-kernel@vger.kernel.org,
        linux-perf-users@vger.kernel.org,
        Alexei Starovoitov <ast@kernel.org>,
        Ben Hutchings <benh@debian.org>, Jiri Olsa <jolsa@kernel.org>,
        Sedat Dilek <sedat.dilek@gmail.com>, bpf@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Apr 18, 2023 at 9:43=E2=80=AFAM Quentin Monnet <quentin@isovalent.c=
om> wrote:
>
> 2023-04-17 10:14 UTC-0700 ~ Ian Rogers <irogers@google.com>
> > On Mon, Apr 17, 2023 at 5:30=E2=80=AFAM Anders Roxell <anders.roxell@li=
naro.org> wrote:
> >>
> >> From: Andres Freund <andres@anarazel.de>
> >>
> >> binutils changed the signature of init_disassemble_info(), which now c=
auses
> >> compilation failures for tools/perf/util/annotate.c, e.g. on debian
> >> unstable.
> >
> > Thanks, I believe the compilation issue may well be resolved by:
> > https://lore.kernel.org/lkml/20230311065753.3012826-8-irogers@google.co=
m/
> > where binutils is made opt-in rather than opt-out.
>
> Hi,
> These commits are to make it possible to build against recent binutils,
> without having to leave it out at compile time, so as I understand they
> address a different issue?

Kind of. We don't want the Linux perf build to break. Previously if
binutils were installed then Linux perf would default to linking with
it and break your build were binutils to change its API. That is no
longer the case as we don't default to linking against binutils. This
was motivated by distributions not being able to link Linux perf with
binutils due to the license incompatibilities. I don't see a problem
supporting linking against newer and older binutils if people want to
on non-distributed binaries. We'll probably need more build
tests/containers to cover the possibilities of this. I'm not sure
what's motivating binutils support other than personal experimentation
though.

Thanks,
Ian


> >
> >> Relevant binutils commit:
> >>
> >>   https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dcommit;h=3D60a3=
da00bd5407f07
> >>
> >> Wire up the feature test and switch to init_disassemble_info_compat(),
> >> which were introduced in prior commits, fixing the compilation failure=
.
> >
> > I was kind of surprised to see no version check ifdef. Is
> > init_disassemble_info_compat is supported in older binutils?
>
> It is not part of binutils, it was introduced in commit a45b3d692623
> ("tools include: add dis-asm-compat.h to handle version differences"),
> which should likely be backported alongside these ones if it hasn't been
> already. Possibly the others from the same series [0], as well?
>
> I think all 5 patches from Andres' series were backported to 5.15 [1].
>
> [0]
> https://lore.kernel.org/all/20220703212551.1114923-1-andres@anarazel.de/t=
/#m999a44663894e235b523ffc41ce87e956019ea72
> [1]
> https://lore.kernel.org/all/e6e2df31-6327-f2ad-3049-0cbfa214ae5c@hauke-m.=
de/t/#u
>
> Best regards,
> Quentin