On Mon, 01 May 2023 at 16:21:55 +0200, Matthias Klose wrote:
> On 01.05.23 14:53, Simon McVittie wrote:
> > This seems inconsistent: I would have expected that binutils-TUPLE would
> > either always provide TUPLE-gold, or never provide TUPLE-gold.
>
> this is an oversight, will fix this in experimental.
Thanks! This part (gold) was what prompted me to open this bug.
> > Similarly, binutils-x86-64-linux-gnu:amd64 provides TUPLE-gp-archive (and
> > other gp- tools) and TUPLE-gprofng, but binutils-x86-64-linux-gnu:ppc64el
> > doesn't provide those.
>
> the profiling parts are not included in the cross packages by intent. Is
> there a use case where these are necessary? Shouldn't you be able to use
> the native packages?
I didn't know and didn't check what these tools are for, I just
noticed while reporting this bug that they were present in native
binutils-x86-64-linux-gnu but not in cross binutils-x86-64-linux-gnu,
which seemed odd. Cross binutils do have TUPLE-gprof, but not
TUPLE-gprofng or the TUPLE-gp- family.
I can see that profiling a non-native executable is likely to lead to
misleading results, because even if you can run it via qemu or something,
the times are not going to reflect how fast or slow a real CPU of the
same architecture would be; so from that point of view, omitting these
makes sense.
For related CPU families like x86_64/i386 and arm64/armhf/armel,
am I correct to assume that there's enough multilib support for
binutils-x86-64-linux-gnu:amd64's gprofng to be able to profile an
i686-linux-gnu executable, and so on? But that would mean that a build
system for build=amd64, host=i386 needs to know that it's OK that
i686-linux-gnu-gprofng won't exist and it should fall back to plain
gprofng (or equivalently, x86_64-linux-gnu-gprofng).
My concern about these was that having them in native binutils but not in
cross-binutils means the command-line "API" of binutils-x86-64-linux-gnu
is different depending on what architecture's version you have. But if
those differences are considered harmless (either because build systems
are expected to fall back from i686-linux-gnu-gprofng to gprofng like
Autotools would, or because using a tuple-prefixed gprofng doesn't actually
make sense and users should stick to the unprefixed one) then that's fine.
smcv
