Added 32-bit Linux builds to Travis script

[AlexAltea]

Added cross-compilation for 32-bit Linux hosts on the Travis configuration file, based on the scripts provided by @maronz (thank you!) on #133 (comment). As you see, there's some extra warnings triggered when compiling the kernel module for 32-bit Linux hosts, but I'll leave that for future PRs.

Signed-off-by: Alexandro Sanchez Bach [email protected]

[raphaelning]

Thanks!

[raphaelning]

nit: If the current directory is our git repo, maybe it would be better to tell wget to use a different location for the downloaded files? E.g. wget -P /tmp/haxm-downloads/ <url> (BTW, -P seems to automatically create the directory). Otherwise this line would copy an extra .deb file, and we would be building from a "dirty" source tree.

[AlexAltea]

Good point! Fixed as of 2403ad3.

[raphaelning]

As you see, there's some extra warnings triggered when compiling the kernel module for 32-bit Linux hosts, but I'll leave that for future PRs.

Sure, most of these GCC warnings are good catches of minor issues. The only one I'm not sure about is:

  CC [M]  /tmp/chroot/trusty_i386/haxm/platforms/linux/components.o
/tmp/chroot/trusty_i386/haxm/platforms/linux/components.c: In function 'hax_vcpu_ioctl':
/tmp/chroot/trusty_i386/haxm/platforms/linux/components.c:455:1: warning: the frame size of 1052 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 }
 ^

which also affects the x86_64 build. Is it because struct hax_msr_data is too big?

[krytarowski]

Is it because struct hax_msr_data is too big?

Actually, it's because the variable of this type is stored more than once on the stack. There are various limits of frame size depending on the context.

[krytarowski]

A quick hack is to define once struct hax_msr_data msrs; in hax_vcpu_ioctl(). A cleaner solution is to allocate it dynamically with a kernel allocator.

[raphaelning]

@krytarowski Thanks! Both solutions sound good to me.

[raphaelning]

With this change, the haxm-linux Travis job finishes in under 3 minutes, which is still much faster than haxm-windows (8m29s). And because these jobs run in parallel, the total build check time should be unchanged.

[raphaelning]

Thanks!