[CRIU] [PATCH] Fix gcc9 build failures
Jeff Law
law at redhat.com
Tue Jan 14 18:33:05 MSK 2020
On Tue, 2020-01-14 at 15:14 +0100, Adrian Reber wrote:
> On Fri, Dec 27, 2019 at 08:32:39AM +0100, Salvatore Bonaccorso wrote:
> > On Fri, Dec 27, 2019 at 12:19:26AM +0100, Adrian Reber wrote:
> > > On Thu, Dec 26, 2019 at 10:43:05PM +0100, Salvatore Bonaccorso wrote:
> > > > On Wed, Jan 09, 2019 at 12:49:11PM +0000, Adrian Reber wrote:
> > > > > From: Adrian Reber <areber at redhat.com>
> > > > >
> > > > > I received this patch from Jeff Law as a fix for build failures with the
> > > > > upcoming GCC 9. The following is Jeff Law's description of the patch:
> > > > >
> > > > > Attached you'll find the fix for criu. You'll see it's just a matter
> > > > > of dropping the sp/esp clobber from the relevant asm statements. THe
> > > > > details:
> > > > >
> > > > > criu has a macro which defines an asm which appears to want to set a new
> > > > > stack pointer, then directly issue a sigreturn call to the kernel. Some
> > > > > variants clobber sp (aarch64, arm, x86), others do not (ppc, s390)
> > > > >
> > > > > While the asm does indeed set a new stack pointer, we never return from
> > > > > a sigreturn syscall -- at least not in the normal way. We actually
> > > > > return back to the point where the process was interrupted by the
> > > > > signal. So describing the affect of the asm on the stack pointer is
> > > > > pedantically correct, it actually has no real effect and can just be
> > > > > dropped to avoid the hard error from gcc-9.
> > > >
> > > > In Debian, with gcc-9 we are seeing as well build failures on ppc64el
> > > > and s390x similarly. See:
> > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=criu&arch=s390x&ver=3.12-1&stamp=1570688225&raw=0
> > > > https://buildd.debian.org/status/fetch.php?pkg=criu&arch=ppc64el&ver=3.12-1&stamp=1570688342&raw=0
> > >
> > > In Fedora I am building CRIU 3.13 without any errors using GCC 9 on
> > > s390x and ppc64le:
> > >
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1377921
> > >
> > > The error you are seeing is, however, interesting as the file has not
> > > seen any changes for a long time. Curious why it fails on Debian.
> >
> > Ack, that is interesting then, because it fails on both architectures
> > back from the first build done with gcc-9, so both 3.12 and 3.13.
> >
> > So needs further investigation.
>
> I was able to get the same error on Fedora 31. It seems this might be
> something which was introduced with later releases of gcc 9. Because it
> used to compile. I opened a PR to get this fixed:
>
> https://github.com/checkpoint-restore/criu/pull/909
It's been a while since I looked at this stuff, but I don't recall it
changing during the gcc-9 cycle. I do think the diagnostic is
conditional on the warnings enabled/disabled on the command line. If
those differ, particularly -Wdeprecated, then that would likely explain
the difference in behavior.
Ultimately removing "sp" clobber is still the right thing to do.
jeff
More information about the CRIU
mailing list