linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Rolf Eike Beer <eb@emlix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Date: Thu, 6 Jun 2019 09:08:07 +0200	[thread overview]
Message-ID: <20190606070807.GA17985@kroah.com> (raw)
In-Reply-To: <CAKv+Gu9Leaq_s2kVNzHx+zkdKFXgQVkouN3M56u5nou5WX=cKg@mail.gmail.com>

On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote:
> On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > > For the record, this is an example of why I think backporting those
> > > clang enablement patches is a bad idea.
> >
> > There's always a risk involved with backports of any kind; more CI
> > coverage can help us mitigate some of these risks in an automated
> > fashion before we get user reports like this.  I meet with the
> > KernelCI folks weekly, so I'll double check on the coverage of the
> > stable tree's branches.  The 0day folks are also very responsive and
> > I've spoken with them a few times, so I'll try to get to the bottom of
> > why this wasn't reported by either of those.
> >
> > Also, these patches help keep Android, CrOS, and Google internal
> > production kernels closer to their upstream sources.
> >
> > > We can't actually build those
> > > kernels with clang, can we? So what is the point? </grumpy>
> >
> > Here's last night's build:
> > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434
> >
> 
> If you are saying that plain upstream 4.9-stable defconfig can be
> built with Clang, then I am pleasantly surprised.

I know some specific configs can, there's no rule that I know of that
'defconfig' support is required.  But then again, it might also work,
try it and see :)

> > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels
> > built with Clang.  I think this number will grow at least one order of
> > magnitude imminently.
> >
> 
> I know that (since you keep reminding me :-)), but obviously, Google
> does not care about changes that regress GCC support.

What are you talking about?  Bugs happen all the time, what specifically
did "Google" do to break gcc support?  If you are referring to this
patch, and it is a regression, of course I will revert it.  But note
that gcc and 4.9 works just fine for all of the other users right now,
remember we do do a lot of testing of these releases.

thanks,

greg k-h

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

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <779905244.a0lJJiZRjM@devpool35>
2019-06-05 16:26 ` Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') Greg KH
2019-06-05 17:27   ` Nick Desaulniers
2019-06-05 17:50     ` Nick Desaulniers
2019-06-06  7:11       ` Rolf Eike Beer
2019-08-02  7:57         ` Greg KH
2019-08-02  8:09           ` Nathan Chancellor
2019-08-02  8:16             ` Rolf Eike Beer
2019-06-05 18:42   ` Ard Biesheuvel
2019-06-05 19:26     ` Greg KH
2019-06-05 20:48     ` Nick Desaulniers
2019-06-06  6:55       ` Ard Biesheuvel
2019-06-06  7:08         ` Greg KH [this message]
2019-06-06  8:58           ` Ard Biesheuvel
2019-06-06  9:34             ` Ard Biesheuvel
2019-06-06  7:38   ` Rolf Eike Beer
2019-06-06  7:50     ` Rolf Eike Beer
2019-06-06  9:01       ` Ard Biesheuvel
2019-06-06  9:40         ` Rolf Eike Beer
2019-06-06  9:54           ` Ard Biesheuvel

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=20190606070807.GA17985@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=eb@emlix.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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).