Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Hagen Paul Pfeifer]

* Matthias Klose | 2020-02-03 22:29:21 [+0100]:

[CCing Alan Modra, H.J. Lu, Nick Clifton & Arnaldo]

Ok, I tried to check what happens:

- Alan Modra modified the bfd_section_* macros (see commit fd3619828e94a)
  upstream (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=summary)
  Or in other words: this patch removed/renamed the macros silently. This was
  back in September last Year. No __attribute__ deprecation warning or other
  information was given a priori to react.
- This went mainline and was now taken by Debian Bullseye the last couple of
  days. RedHat and other distributions will probably run in the same problems,
  once they upgrade binutils.
- Linux perf and other applications build on these functionality are now
  doomed.

>binutils doesn't have any comitment to a stable ABI/API for libopcodes and
>libbfd.

Sure? They exposed bfd_get_section_flags and friends in bfd.h - it was not
hidden somewhere in private header files nor was it guarded by any other
measure. Correct me if I am wrong!

And: the functions/macros where used in the wild! They where helpful and
serviceable to the broader audience - which is (sorry: "was" :-) great!

The following patch fixed the problem for me to build Linux perf again:

--- /usr/include/bfd.h	2020-02-04 15:24:36.746534674 +0000
+++ /usr/include/bfd.new.h	2020-02-04 15:24:39.486542126 +0000
@@ -1243,6 +1243,11 @@
   return (sec->flags & SEC_IS_COMMON) != 0;
 }

+#define bfd_get_section_flags(bfd, ptr) ((void) bfd, (ptr)->flags)
+#define bfd_get_section_userdata(bfd, ptr) ((void) bfd, (ptr)->userdata)
+#define bfd_get_section_vma(bfd, ptr) ((void) bfd, (ptr)->vma)
+#define bfd_get_section_size(ptr) ((ptr)->size)
+


Note: for binutils ./bfd/bfd-in.h should be adjusted - sure.

Hagen Paul Pfeifer

>> It seems other people (kernel folks, Stephen) have the identical error as
>> well: https://lkml.org/lkml/2020/1/30/1005
>> Stephen: or is the bug fixed somewhere else? Do you have an workaround?a
>
>I don't have a work-around. If you rely on binutils internals, you really should
>adjust to binutils upstream.

Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Romain Naour]

Hi All,

Le 04/02/2020 à 16:35, Hagen Paul Pfeifer a écrit :
> * Matthias Klose | 2020-02-03 22:29:21 [+0100]:
> 
> [CCing Alan Modra, H.J. Lu, Nick Clifton & Arnaldo]
> 
> Ok, I tried to check what happens:
> 
> - Alan Modra modified the bfd_section_* macros (see commit fd3619828e94a)
>   upstream (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=summary)
>   Or in other words: this patch removed/renamed the macros silently. This was
>   back in September last Year. No __attribute__ deprecation warning or other
>   information was given a priori to react.
> - This went mainline and was now taken by Debian Bullseye the last couple of
>   days. RedHat and other distributions will probably run in the same problems,
>   once they upgrade binutils.
> - Linux perf and other applications build on these functionality are now
>   doomed.

Binutils 2.34 broke also elf2flt tool:

https://github.com/uclinux-dev/elf2flt/blob/453398f917d167f8c308c8f997270c48ae8f8b12/elf2flt.c#L326

elf2flt is used in Buildroot build for armv7m (cortex-m4) and m68k-codefire.

https://gitlab.com/kubu93/toolchains-builder/-/jobs/423715926

Best regards,
Romain

> 
>> binutils doesn't have any comitment to a stable ABI/API for libopcodes and
>> libbfd.
> 
> Sure? They exposed bfd_get_section_flags and friends in bfd.h - it was not
> hidden somewhere in private header files nor was it guarded by any other
> measure. Correct me if I am wrong!
> 
> And: the functions/macros where used in the wild! They where helpful and
> serviceable to the broader audience - which is (sorry: "was" :-) great!
> 
> The following patch fixed the problem for me to build Linux perf again:
> 
> --- /usr/include/bfd.h	2020-02-04 15:24:36.746534674 +0000
> +++ /usr/include/bfd.new.h	2020-02-04 15:24:39.486542126 +0000
> @@ -1243,6 +1243,11 @@
>    return (sec->flags & SEC_IS_COMMON) != 0;
>  }
> 
> +#define bfd_get_section_flags(bfd, ptr) ((void) bfd, (ptr)->flags)
> +#define bfd_get_section_userdata(bfd, ptr) ((void) bfd, (ptr)->userdata)
> +#define bfd_get_section_vma(bfd, ptr) ((void) bfd, (ptr)->vma)
> +#define bfd_get_section_size(ptr) ((ptr)->size)
> +
> 
> 
> Note: for binutils ./bfd/bfd-in.h should be adjusted - sure.
> 
> Hagen Paul Pfeifer
> 
>>> It seems other people (kernel folks, Stephen) have the identical error as
>>> well: https://lkml.org/lkml/2020/1/30/1005
>>> Stephen: or is the bug fixed somewhere else? Do you have an workaround?a
>>
>> I don't have a work-around. If you rely on binutils internals, you really should
>> adjust to binutils upstream.

Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Alan Modra]

The binutils and gdb projects do not even pretend to a stable ABI or
API for libbfd and libopcodes.  Particularly not ABI, that gets broken
on almost every week.  perf and other projects that want to use libbfd
or libopcodes are of course welcome to do so, but they then need to
deal with the changing API.  Complaints that Nick, Alan, or H.J. Lu
have broken perf or similar *will be ignored*, except possibly to tell
you that you may as well stop complaining.

I've said before that the most obvious way to deal with the unstable
API is to import a snapshot of the libbfd and libopcodes code into
those projects and merge from upstream as new upstream support becomes
desirable.  That's not hard to do!

-- 
Alan Modra
Australia Development Lab, IBM

Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Wed, 2020-02-05 at 09:59 +1030, Alan Modra wrote:
> The binutils and gdb projects do not even pretend to a stable ABI or
> API for libbfd and libopcodes.  Particularly not ABI, that gets broken
> on almost every week.  perf and other projects that want to use libbfd
> or libopcodes are of course welcome to do so, but they then need to
> deal with the changing API.  Complaints that Nick, Alan, or H.J. Lu
> have broken perf or similar *will be ignored*, except possibly to tell
> you that you may as well stop complaining.
> 
> I've said before that the most obvious way to deal with the unstable
> API is to import a snapshot of the libbfd and libopcodes code into
> those projects and merge from upstream as new upstream support becomes
> desirable.  That's not hard to do!

Maybe they could also relicense perf to be GPLv3 compatible. :-)

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                          - John Lennon



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

[Thomas Backlund]

Den 5.2.2020 kl. 01:29, skrev Alan Modra:
> The binutils and gdb projects do not even pretend to a stable ABI or
> API for libbfd and libopcodes.  Particularly not ABI, that gets broken
> on almost every week.  perf and other projects that want to use libbfd
> or libopcodes are of course welcome to do so, but they then need to
> deal with the changing API.  Complaints that Nick, Alan, or H.J. Lu
> have broken perf or similar *will be ignored*, except possibly to tell
> you that you may as well stop complaining.
> 
> I've said before that the most obvious way to deal with the unstable
> API is to import a snapshot of the libbfd and libopcodes code into
> those projects and merge from upstream as new upstream support becomes
> desirable.  That's not hard to do!
> 


Yeah, it broke various bits for us too, but then again ...

The breakage is basically a variant of:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/stable-api-nonsense.rst

What goes around comes around :)

Now we just need fixes all over :)

--
Thomas