linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Rolf Eike Beer <eb@emlix.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	stable@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
Date: Wed, 12 Jun 2019 09:50:49 +0200	[thread overview]
Message-ID: <20190612075049.GB17662@kroah.com> (raw)
In-Reply-To: <3659495.RxnUGBN4mp@devpool35>

On Wed, Jun 12, 2019 at 09:19:15AM +0200, Rolf Eike Beer wrote:
> Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
> > On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
> > > On Thu, Jun 6, 2019 at 5:29 PM Greg KH <greg@kroah.com> wrote:
> > > > And if you want this, you should look at how the backports to 4.14.y
> > > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use
> > > > feature checks instead of version checks"), as that gets really messy...
> > > 
> > > I am confused -- I interpreted Rolf's message as reporting that he
> > > already successfully built 4.9 by applying a6e60d84989f
> > > ("include/linux/module.h: copy __init/__exit attrs to
> > > init/cleanup_module") and manually fixing it up. But maybe I am
> > > completely wrong... :-)
> > 
> > "manually fixing it up" means "hacked it to pieces" to me, I have no
> > idea what the end result really was :)
> > 
> > If someone wants to send me some patches I can actually apply, that
> > would be best...
> 
> Hi all,
> 
> the patch I actually used was this:
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 8fa38d3e7538..f5bc4c046461 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -129,13 +129,13 @@ extern void cleanup_module(void);
>  #define module_init(initfn)					\
>  	static inline initcall_t __maybe_unused __inittest(void)		\
>  	{ return initfn; }					\
> -	int init_module(void) __attribute__((alias(#initfn)));
> +	int init_module(void) __attribute__((__copy__(initfn))) __attribute__((alias(#initfn)));
>  
>  /* This is only required if you want to be unloadable. */
>  #define module_exit(exitfn)					\
>  	static inline exitcall_t __maybe_unused __exittest(void)		\
>  	{ return exitfn; }					\
> -	void cleanup_module(void) __attribute__((alias(#exitfn)));
> +	void cleanup_module(void) __attribute__((__copy__(exitfn))) __attribute__((alias(#exitfn)));
>  
>  #endif
>  
> 
> So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If
> yes then we can probably get this patches into shape.

Eventually, yes, we (or at least I) will want to build 4.9.x with gcc
9.x.  We went through this same process for gcc 8.x as all of my builder
test machines switched their default version of gcc...

thanks,

greg k-h

      reply	other threads:[~2019-06-12  7:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 13:16 Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target … Rolf Eike Beer
2019-06-06 15:27 ` Greg KH
2019-06-06 15:29   ` Greg KH
2019-06-06 18:25     ` Miguel Ojeda
2019-06-06 18:59       ` Greg KH
2019-06-08 12:00         ` Miguel Ojeda
2019-08-02  8:17           ` Rolf Eike Beer
2019-08-02  8:28             ` Greg KH
2019-08-02 10:19             ` Miguel Ojeda
2019-08-02 10:33               ` Greg KH
2019-08-02 10:39                 ` Miguel Ojeda
2019-08-02 11:26                   ` Greg KH
2019-08-02 11:00                 ` Miguel Ojeda
2019-08-02 11:25                   ` Greg KH
2019-08-02 13:01                     ` Miguel Ojeda
2019-08-02 15:56                       ` Greg KH
2019-08-02 16:55                         ` Miguel Ojeda
2019-08-05 11:55                           ` Greg KH
2019-08-05 12:47                             ` Miguel Ojeda
2019-06-12  7:19         ` Rolf Eike Beer
2019-06-12  7:50           ` Greg KH [this message]

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=20190612075049.GB17662@kroah.com \
    --to=greg@kroah.com \
    --cc=eb@emlix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).