✗ travis-ci: failure for Add architecture support for s390x (rev2)

Submitted by Michael Holzheu on June 30, 2017, 9:02 a.m.

Details

Message ID 20170630110201.3b747490@TP-holzheu
State New
Headers show

Patch hide | download patch | download mbox

diff --git a/compel/Makefile b/compel/Makefile
index ebe006d..0bc2324 100644
--- a/compel/Makefile
+++ b/compel/Makefile
@@ -37,7 +37,7 @@  endif
 # We assume that compel code does not change floating point registers.
 # On s390 gcc uses fprs to cache gprs. Therefore disable floating point
 # with -msoft-float.
-ifeq ($(filter s390x,$(ARCH)),)
+ifeq ($(ARCH),s390)
 CFLAGS += -msoft-float
 HOSTCFLAGS += -msoft-float
 endif
diff --git a/compel/plugins/Makefile b/compel/plugins/Makefile
index aa09e20..39251b0 100644
--- a/compel/plugins/Makefile
+++ b/compel/plugins/Makefile
@@ -10,7 +10,7 @@  PLUGIN_ARCH_DIR		:= compel/arch/$(ARCH)/plugins
 # We assume that compel code does not change floating point registers.
 # On s390 gcc uses fprs to cache gprs. Therefore disable floating point
 # with -msoft-float.
-ifeq ($(filter s390x,$(ARCH)),)
+ifeq ($(ARCH), s390)
 CFLAGS += -msoft-float
 endif
 
-- 
1.9.1


> 
> 
> Next, on arm it's:
> 
>      DEP      compel/plugins/std/infect.d
>    In file included from /usr/include/arpa/inet.h:21:0,
>                     from compel/include/uapi/compel/plugins/std/syscall-types.h:9,
>                     from compel/include/uapi/compel/plugins/std/syscall.h:4,
>                     from compel/include/uapi/compel/plugins/std.h:5,
>                     from compel/plugins/std/infect.c:1:
>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
>     #  include <sys/cdefs.h>
> 
> This is strange, as this shown an error in a system header, rather than in criu/compel
> ones :\

Hmm, I don't understand this one either.

> 
> 
> On x86 the build has passed, but the very first test run revealed mis-compiled
> ELF parser in compel:
> 
>    ======================== Run zdtm/transition/shmem in h ========================
>    Start test
>    ./shmem --pidfile=shmem.pid --outfile=shmem.out
>    Run criu dump
>    =[log]=> dump/zdtm/transition/shmem/26/1/dump.log
>    ------------------------ grep Error ------------------------
>    (00.091109) Found task size of 7ffffffff000
>    (00.130220) Warn  (criu/net.c:2504): Unable to get a socket network namespace
>    (00.130353) No /proc/self/ns/pid_for_children
>    (00.130461) vdso: Parsing at 7ffe37df6000 7ffe37df8000
>    (00.130469) Error (criu/pie-util-vdso.c:97): vdso: ELF header magic mismatch
> 
> The last line is causing the dump to fail.

Sorry, my bad - this was caused by a last-minute change where I did not
re-test on x86.

The following fixes the problem:
---
[PATCH] Fix big endian byte order checks

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 criu/pie/util-vdso.c | 2 +-
 criu/sk-netlink.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/criu/pie/util-vdso.c b/criu/pie/util-vdso.c
index 4a6138e..6213df9 100644
--- a/criu/pie/util-vdso.c
+++ b/criu/pie/util-vdso.c
@@ -68,7 +68,7 @@  static unsigned long elf_hash(const unsigned char *name)
 	return h;
 }
 
-#ifdef __ORDER_BIG_ENDIAN__
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 #define BORD ELFDATA2MSB /* 0x02 */
 #else
 #define BORD ELFDATA2LSB /* 0x01 */
diff --git a/criu/sk-netlink.c b/criu/sk-netlink.c
index bfa6831..a9d73c5 100644
--- a/criu/sk-netlink.c
+++ b/criu/sk-netlink.c
@@ -107,7 +107,7 @@  static int dump_one_netlink_fd(int lfd, u32 id, const struct fd_parms *p)
 		 * On 64-bit sk->gsize is multiple to 8 bytes (sizeof(long)),
 		 * so remove the last 4 bytes if they are empty.
 		 */
-#ifdef __ORDER_BIG_ENDIAN__
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 		/*
 		 * Big endian swap: Ugly hack for zdtm/static/sk-netlink
 		 *

Comments

Pavel Emelyanov June 30, 2017, 10:36 a.m.
>> Next, on arm it's:
>>
>>      DEP      compel/plugins/std/infect.d
>>    In file included from /usr/include/arpa/inet.h:21:0,
>>                     from compel/include/uapi/compel/plugins/std/syscall-types.h:9,
>>                     from compel/include/uapi/compel/plugins/std/syscall.h:4,
>>                     from compel/include/uapi/compel/plugins/std.h:5,
>>                     from compel/plugins/std/infect.c:1:
>>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
>>     #  include <sys/cdefs.h>
>>
>> This is strange, as this shown an error in a system header, rather than in criu/compel
>> ones :\
> 
> Hmm, I don't understand this one either.

Michael, do you have an access to some ARM box?

If no, Dima, Andrey, IIRC the ARM build is performed on x86 node, but with some
help of qemu. Would you help Michael set up this build locally on his node
(Michael, I'm sure you have x86 one :D ).

-- Pavel
Pavel Emelyanov June 30, 2017, 10:43 a.m.
>>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
>>     #  include <sys/cdefs.h>
>>
>> This is strange, as this shown an error in a system header, rather than in criu/compel
>> ones :\
> 
> Hmm, I don't understand this one either.
> 

BTW, if that can be anyhow helpful -- if you have a github account and a criu for on it, you 
can enable Travis hooks for it, and every push to every branch will start build validation on 
travis. With this you can have build results much faster, than if (re-)sending the patches
into the mailing list.

-- Pavel
Michael Holzheu June 30, 2017, 2:22 p.m.
Am Fri, 30 Jun 2017 13:43:26 +0300
schrieb Pavel Emelyanov <xemul@virtuozzo.com>:

> >>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
> >>     #  include <sys/cdefs.h>
> >>
> >> This is strange, as this shown an error in a system header, rather than in criu/compel
> >> ones :\
> > 
> > Hmm, I don't understand this one either.
> > 
> 
> BTW, if that can be anyhow helpful -- if you have a github account and a criu for on it, you 
> can enable Travis hooks for it, and every push to every branch will start build validation on 
> travis. With this you can have build results much faster, than if (re-)sending the patches
> into the mailing list.

I forked criu and pushed the patches to the "ibm_criu-dev-v2" branch:

https://github.com/michael-holzheu/criu/commits/ibm_criu-dev-v2

At least for the following travis run everything was green:

https://travis-ci.org/michael-holzheu/criu/builds/248768999

Michael
Pavel Emelyanov June 30, 2017, 4:28 p.m.
On 06/30/2017 05:22 PM, Michael Holzheu wrote:
> Am Fri, 30 Jun 2017 13:43:26 +0300
> schrieb Pavel Emelyanov <xemul@virtuozzo.com>:
> 
>>>>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
>>>>     #  include <sys/cdefs.h>
>>>>
>>>> This is strange, as this shown an error in a system header, rather than in criu/compel
>>>> ones :\
>>>
>>> Hmm, I don't understand this one either.
>>>
>>
>> BTW, if that can be anyhow helpful -- if you have a github account and a criu for on it, you 
>> can enable Travis hooks for it, and every push to every branch will start build validation on 
>> travis. With this you can have build results much faster, than if (re-)sending the patches
>> into the mailing list.
> 
> I forked criu and pushed the patches to the "ibm_criu-dev-v2" branch:
> 
> https://github.com/michael-holzheu/criu/commits/ibm_criu-dev-v2

Yup. With all the fixes discovered during previous review :)

> At least for the following travis run everything was green:
> 
> https://travis-ci.org/michael-holzheu/criu/builds/248768999

That's awesome! This means, that the changes made on top of this set fixed
everything :)

I would appreciate if you merge the recent fixes into respective patches and
re-send the v3 series with Dmitry's acks/reviews, so we could finally merge
the code into dev branch.

-- Pavel
Michael Holzheu June 30, 2017, 5:31 p.m.
Am Fri, 30 Jun 2017 19:28:57 +0300
schrieb Pavel Emelyanov <xemul@virtuozzo.com>:

> On 06/30/2017 05:22 PM, Michael Holzheu wrote:
> > Am Fri, 30 Jun 2017 13:43:26 +0300
> > schrieb Pavel Emelyanov <xemul@virtuozzo.com>:
> > 
> >>>>    /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
> >>>>     #  include <sys/cdefs.h>
> >>>>
> >>>> This is strange, as this shown an error in a system header, rather than in criu/compel
> >>>> ones :\
> >>>
> >>> Hmm, I don't understand this one either.
> >>>
> >>
> >> BTW, if that can be anyhow helpful -- if you have a github account and a criu for on it, you 
> >> can enable Travis hooks for it, and every push to every branch will start build validation on 
> >> travis. With this you can have build results much faster, than if (re-)sending the patches
> >> into the mailing list.
> > 
> > I forked criu and pushed the patches to the "ibm_criu-dev-v2" branch:
> > 
> > https://github.com/michael-holzheu/criu/commits/ibm_criu-dev-v2
> 
> Yup. With all the fixes discovered during previous review :)
> 
> > At least for the following travis run everything was green:
> > 
> > https://travis-ci.org/michael-holzheu/criu/builds/248768999
> 
> That's awesome! This means, that the changes made on top of this set fixed
> everything :)
> 
> I would appreciate if you merge the recent fixes into respective patches and
> re-send the v3 series with Dmitry's acks/reviews, so we could finally merge
> the code into dev branch.

Sure - I will re-send v3 patches.

Michael