Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Romain Naour <romain.naour@smile.fr>
To: Hagen Paul Pfeifer <hagen@jauu.net>, Matthias Klose <doko@debian.org>
Cc: 950414@bugs.debian.org, Ben Hutchings <ben@decadent.org.uk>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	binutils <binutils@sourceware.org>,
	gdb@sourceware.org, Alan Modra <amodra@gmail.com>,
	"H.J. Lu" <hjl.tools@gmail.com>, Nick Clifton <nickc@redhat.com>
Subject: Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
Date: Tue, 04 Feb 2020 22:04:00 -0000	[thread overview]
Message-ID: <baec5492-441d-45a6-6fe9-15398120968a@smile.fr> (raw)
In-Reply-To: <20200204153557.GA280113@virgo>

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.


  reply	other threads:[~2020-02-04 22:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200201095306.GD9786@laniakea>
     [not found] ` <005fbdf3-a9c6-36d8-c2e8-0d307de5a40d@debian.org>
     [not found]   ` <20200203210310.GA217509@virgo>
     [not found]     ` <d91b6b94-c326-b972-483d-f586fb8a0d4b@debian.org>
2020-02-04 15:36       ` Hagen Paul Pfeifer
2020-02-04 22:04         ` Romain Naour [this message]
2020-02-04 23:29           ` Alan Modra
2020-02-04 23:48             ` Ben Hutchings
2020-02-05  8:35             ` Thomas Backlund

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=baec5492-441d-45a6-6fe9-15398120968a@smile.fr \
    --to=romain.naour@smile.fr \
    --cc=950414@bugs.debian.org \
    --cc=amodra@gmail.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=ben@decadent.org.uk \
    --cc=binutils@sourceware.org \
    --cc=doko@debian.org \
    --cc=gdb@sourceware.org \
    --cc=hagen@jauu.net \
    --cc=hjl.tools@gmail.com \
    --cc=nickc@redhat.com \
    --cc=sfr@canb.auug.org.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox