Mailing List Archive

Building Xen 4.14 on Debian Bullseye (WAS Re: Xen compile error)
Hi,

Thank you for the report.

On 08/10/2020 13:28, ba1020@protonmail.ch wrote:
> i try to compile the lates Release 4.14.0 and get stuck here
>
In general, I would suggest to use the branch stable-4.14 or
staging-4.14 as we may have fixed some bugs which unfortunately slipped
in the release.

However, for your situation, this would have unfortunately not helped
because the commit d25cc3ec93eb "libxl: workaround gcc 10.2
maybe-uninitialized warning" is not present.

I know that Debian is looking to get Xen 4.14 build with the GCC 10. I
have CCed Ian and Hans who may be able to assist you if you encounter
more bug.

In regard to upstream, I think we want to get 4.14 building out-of-box
with GCC 10 so distros can easily adopt it.

I will send an e-mail to request a backport for the commit d25cc3ec93eb
"libxl: workaround gcc 10.2 maybe-uninitialized warning".

Best regards,

>
>
> libxlu_pci.c: In function ‘xlu_pci_parse_bdf’:
> libxlu_pci.c:32:18: error: ‘func’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 32 | pcidev->func = func;
> | ~~~~~~~~~~~~~^~~~~~
> libxlu_pci.c:51:29: note: ‘func’ was declared here
> 51 | unsigned dom, bus, dev, func, vslot = 0;
> | ^~~~
> libxlu_pci.c:31:17: error: ‘dev’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 31 | pcidev->dev = dev;
> | ~~~~~~~~~~~~^~~~~
> libxlu_pci.c:51:24: note: ‘dev’ was declared here
> 51 | unsigned dom, bus, dev, func, vslot = 0;
> | ^~~
> libxlu_pci.c:30:17: error: ‘bus’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 30 | pcidev->bus = bus;
> | ~~~~~~~~~~~~^~~~~
> libxlu_pci.c:51:19: note: ‘bus’ was declared here
> 51 | unsigned dom, bus, dev, func, vslot = 0;
> | ^~~
> libxlu_pci.c:29:20: error: ‘dom’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 29 | pcidev->domain = domain;
> | ~~~~~~~~~~~~~~~^~~~~~~~
> libxlu_pci.c:51:14: note: ‘dom’ was declared here
> 51 | unsigned dom, bus, dev, func, vslot = 0;
> | ^~~
> cc1: all warnings being treated as errors
> make[5]: *** [/home/adminjs/xen/tools/libxl/../../tools/Rules.mk:216: libxlu_pci.o] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: Leaving directory '/home/adminjs/xen/tools/libxl'
> make[4]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:240: subdir-install-libxl] Error 2
> make[4]: Leaving directory '/home/adminjs/xen/tools'
> make[3]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:235: subdirs-install] Error 2
> make[3]: Leaving directory '/home/adminjs/xen/tools'
> make[2]: *** [Makefile:72: install] Error 2
> make[2]: Leaving directory '/home/adminjs/xen/tools'
> make[1]: *** [Makefile:134: install-tools] Error 2
> make[1]: Leaving directory '/home/adminjs/xen'
> make: *** [Makefile:170: world] Error 2


--
Julien Grall
Re: Building Xen 4.14 on Debian Bullseye (WAS Re: Xen compile error) [ In reply to ]
On 10/9/20 7:40 PM, Julien Grall wrote:
> Hi,
>
> Thank you for the report.
>
> On 08/10/2020 13:28, ba1020@protonmail.ch wrote:
>> i try to compile the lates Release 4.14.0 and get stuck here
>>
> In general, I would suggest to use the branch stable-4.14 or
> staging-4.14 as we may have fixed some bugs which unfortunately slipped
> in the release.
>
> However, for your situation, this would have unfortunately not helped
> because the commit d25cc3ec93eb "libxl: workaround gcc 10.2
> maybe-uninitialized warning" is not present.
>
> I know that Debian is looking to get Xen 4.14 build with the GCC 10. I
> have CCed Ian and Hans who may be able to assist you if you encounter
> more bug.

For Debian, we need to get it to build on a couple of archs. We're
currently trying to get over this hurdle.

https://buildd.debian.org/status/package.php?p=xen&suite=experimental

You need at least these:

* d25cc3ec93eb ("libxl: workaround gcc 10.2 maybe-uninitialized warning")
* fff1b7f50e75 ("libxl: fix -Werror=stringop-truncation in
libxl__prepare_sockaddr_un")
* 5d45ecabe3c0 ("xen/arm64: force gcc 10+ to always inline generic
atomics helpers")

There's also a failure in tools/xenpmd [armhf], which is caused by a
compiler bug, we chose to unblock it by putting in a temporary
workaround for now, waiting for what upstream will do about it (or while
waiting for fix in gcc):

https://salsa.debian.org/xen-team/debian-xen/-/commit/bb84bb24b55b7906c8dadd736ae1ee0ac22b1e12
-> "tools/xenpmd: work around gcc 10 bug for xenpmd.c", commit id might
be lost because of heavy rebasing.

> In regard to upstream, I think we want to get 4.14 building out-of-box
> with GCC 10 so distros can easily adopt it.

The three ones mentioned above are definitely backport candidates for
4.14 already.

> I will send an e-mail to request a backport for the commit d25cc3ec93eb
> "libxl: workaround gcc 10.2 maybe-uninitialized warning".
>
> Best regards,
>
>>
>>
>> libxlu_pci.c: In function ‘xlu_pci_parse_bdf’:
>> libxlu_pci.c:32:18: error: ‘func’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> 32 | pcidev->func = func;
>> | ~~~~~~~~~~~~~^~~~~~
>> libxlu_pci.c:51:29: note: ‘func’ was declared here
>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>> | ^~~~
>> libxlu_pci.c:31:17: error: ‘dev’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> 31 | pcidev->dev = dev;
>> | ~~~~~~~~~~~~^~~~~
>> libxlu_pci.c:51:24: note: ‘dev’ was declared here
>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>> | ^~~
>> libxlu_pci.c:30:17: error: ‘bus’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> 30 | pcidev->bus = bus;
>> | ~~~~~~~~~~~~^~~~~
>> libxlu_pci.c:51:19: note: ‘bus’ was declared here
>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>> | ^~~
>> libxlu_pci.c:29:20: error: ‘dom’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> 29 | pcidev->domain = domain;
>> | ~~~~~~~~~~~~~~~^~~~~~~~
>> libxlu_pci.c:51:14: note: ‘dom’ was declared here
>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>> | ^~~
>> cc1: all warnings being treated as errors
>> make[5]: *** [/home/adminjs/xen/tools/libxl/../../tools/Rules.mk:216: libxlu_pci.o] Error 1
>> make[5]: *** Waiting for unfinished jobs....
>> make[5]: Leaving directory '/home/adminjs/xen/tools/libxl'
>> make[4]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:240: subdir-install-libxl] Error 2
>> make[4]: Leaving directory '/home/adminjs/xen/tools'
>> make[3]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:235: subdirs-install] Error 2
>> make[3]: Leaving directory '/home/adminjs/xen/tools'
>> make[2]: *** [Makefile:72: install] Error 2
>> make[2]: Leaving directory '/home/adminjs/xen/tools'
>> make[1]: *** [Makefile:134: install-tools] Error 2
>> make[1]: Leaving directory '/home/adminjs/xen'
>> make: *** [Makefile:170: world] Error 2

Have fun,
Hans
Re: Building Xen 4.14 on Debian Bullseye (WAS Re: Xen compile error) [ In reply to ]
Hi,

> On 9 Oct 2020, at 22:14, Hans van Kranenburg <hans@knorrie.org> wrote:
>
> On 10/9/20 7:40 PM, Julien Grall wrote:
>> Hi,
>>
>> Thank you for the report.
>>
>> On 08/10/2020 13:28, ba1020@protonmail.ch wrote:
>>> i try to compile the lates Release 4.14.0 and get stuck here
>>>
>> In general, I would suggest to use the branch stable-4.14 or
>> staging-4.14 as we may have fixed some bugs which unfortunately slipped
>> in the release.
>>
>> However, for your situation, this would have unfortunately not helped
>> because the commit d25cc3ec93eb "libxl: workaround gcc 10.2
>> maybe-uninitialized warning" is not present.
>>
>> I know that Debian is looking to get Xen 4.14 build with the GCC 10. I
>> have CCed Ian and Hans who may be able to assist you if you encounter
>> more bug.
>
> For Debian, we need to get it to build on a couple of archs. We're
> currently trying to get over this hurdle.
>
> https://buildd.debian.org/status/package.php?p=xen&suite=experimental
>
> You need at least these:
>
> * d25cc3ec93eb ("libxl: workaround gcc 10.2 maybe-uninitialized warning")
> * fff1b7f50e75 ("libxl: fix -Werror=stringop-truncation in
> libxl__prepare_sockaddr_un")
> * 5d45ecabe3c0 ("xen/arm64: force gcc 10+ to always inline generic
> atomics helpers")
>
> There's also a failure in tools/xenpmd [armhf], which is caused by a
> compiler bug, we chose to unblock it by putting in a temporary
> workaround for now, waiting for what upstream will do about it (or while
> waiting for fix in gcc):
>
> https://salsa.debian.org/xen-team/debian-xen/-/commit/bb84bb24b55b7906c8dadd736ae1ee0ac22b1e12
> -> "tools/xenpmd: work around gcc 10 bug for xenpmd.c", commit id might
> be lost because of heavy rebasing.

I also came into this one on friday.

I will push a patch today or tomorrow to fix it on xen-devel and we should backport it after.

>
>> In regard to upstream, I think we want to get 4.14 building out-of-box
>> with GCC 10 so distros can easily adopt it.
>
> The three ones mentioned above are definitely backport candidates for
> 4.14 already.

We need to backport those to 4.14 definitely.
Yocto is also using gcc10 so i can also use it to test those.

Regards
Bertrand

>
>> I will send an e-mail to request a backport for the commit d25cc3ec93eb
>> "libxl: workaround gcc 10.2 maybe-uninitialized warning".
>>
>> Best regards,
>>
>>>
>>>
>>> libxlu_pci.c: In function ‘xlu_pci_parse_bdf’:
>>> libxlu_pci.c:32:18: error: ‘func’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>> 32 | pcidev->func = func;
>>> | ~~~~~~~~~~~~~^~~~~~
>>> libxlu_pci.c:51:29: note: ‘func’ was declared here
>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>> | ^~~~
>>> libxlu_pci.c:31:17: error: ‘dev’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>> 31 | pcidev->dev = dev;
>>> | ~~~~~~~~~~~~^~~~~
>>> libxlu_pci.c:51:24: note: ‘dev’ was declared here
>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>> | ^~~
>>> libxlu_pci.c:30:17: error: ‘bus’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>> 30 | pcidev->bus = bus;
>>> | ~~~~~~~~~~~~^~~~~
>>> libxlu_pci.c:51:19: note: ‘bus’ was declared here
>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>> | ^~~
>>> libxlu_pci.c:29:20: error: ‘dom’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>> 29 | pcidev->domain = domain;
>>> | ~~~~~~~~~~~~~~~^~~~~~~~
>>> libxlu_pci.c:51:14: note: ‘dom’ was declared here
>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>> | ^~~
>>> cc1: all warnings being treated as errors
>>> make[5]: *** [/home/adminjs/xen/tools/libxl/../../tools/Rules.mk:216: libxlu_pci.o] Error 1
>>> make[5]: *** Waiting for unfinished jobs....
>>> make[5]: Leaving directory '/home/adminjs/xen/tools/libxl'
>>> make[4]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:240: subdir-install-libxl] Error 2
>>> make[4]: Leaving directory '/home/adminjs/xen/tools'
>>> make[3]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:235: subdirs-install] Error 2
>>> make[3]: Leaving directory '/home/adminjs/xen/tools'
>>> make[2]: *** [Makefile:72: install] Error 2
>>> make[2]: Leaving directory '/home/adminjs/xen/tools'
>>> make[1]: *** [Makefile:134: install-tools] Error 2
>>> make[1]: Leaving directory '/home/adminjs/xen'
>>> make: *** [Makefile:170: world] Error 2
>
> Have fun,
> Hans
Re: Building Xen 4.14 on Debian Bullseye (WAS Re: Xen compile error) [ In reply to ]
Hi,

> On 12 Oct 2020, at 10:57, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>
> Hi,
>
>> On 9 Oct 2020, at 22:14, Hans van Kranenburg <hans@knorrie.org> wrote:
>>
>> On 10/9/20 7:40 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> Thank you for the report.
>>>
>>> On 08/10/2020 13:28, ba1020@protonmail.ch wrote:
>>>> i try to compile the lates Release 4.14.0 and get stuck here
>>>>
>>> In general, I would suggest to use the branch stable-4.14 or
>>> staging-4.14 as we may have fixed some bugs which unfortunately slipped
>>> in the release.
>>>
>>> However, for your situation, this would have unfortunately not helped
>>> because the commit d25cc3ec93eb "libxl: workaround gcc 10.2
>>> maybe-uninitialized warning" is not present.
>>>
>>> I know that Debian is looking to get Xen 4.14 build with the GCC 10. I
>>> have CCed Ian and Hans who may be able to assist you if you encounter
>>> more bug.
>>
>> For Debian, we need to get it to build on a couple of archs. We're
>> currently trying to get over this hurdle.
>>
>> https://buildd.debian.org/status/package.php?p=xen&suite=experimental
>>
>> You need at least these:
>>
>> * d25cc3ec93eb ("libxl: workaround gcc 10.2 maybe-uninitialized warning")
>> * fff1b7f50e75 ("libxl: fix -Werror=stringop-truncation in
>> libxl__prepare_sockaddr_un")
>> * 5d45ecabe3c0 ("xen/arm64: force gcc 10+ to always inline generic
>> atomics helpers")
>>
>> There's also a failure in tools/xenpmd [armhf], which is caused by a
>> compiler bug, we chose to unblock it by putting in a temporary
>> workaround for now, waiting for what upstream will do about it (or while
>> waiting for fix in gcc):
>>
>> https://salsa.debian.org/xen-team/debian-xen/-/commit/bb84bb24b55b7906c8dadd736ae1ee0ac22b1e12
>> -> "tools/xenpmd: work around gcc 10 bug for xenpmd.c", commit id might
>> be lost because of heavy rebasing.
>
> I also came into this one on friday.
>
> I will push a patch today or tomorrow to fix it on xen-devel and we should backport it after.

I pushed a patch on the mailing list for this one:
https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg00899.html

Bertrand

>
>>
>>> In regard to upstream, I think we want to get 4.14 building out-of-box
>>> with GCC 10 so distros can easily adopt it.
>>
>> The three ones mentioned above are definitely backport candidates for
>> 4.14 already.
>
> We need to backport those to 4.14 definitely.
> Yocto is also using gcc10 so i can also use it to test those.
>
> Regards
> Bertrand
>
>>
>>> I will send an e-mail to request a backport for the commit d25cc3ec93eb
>>> "libxl: workaround gcc 10.2 maybe-uninitialized warning".
>>>
>>> Best regards,
>>>
>>>>
>>>>
>>>> libxlu_pci.c: In function ‘xlu_pci_parse_bdf’:
>>>> libxlu_pci.c:32:18: error: ‘func’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>>> 32 | pcidev->func = func;
>>>> | ~~~~~~~~~~~~~^~~~~~
>>>> libxlu_pci.c:51:29: note: ‘func’ was declared here
>>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>>> | ^~~~
>>>> libxlu_pci.c:31:17: error: ‘dev’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>>> 31 | pcidev->dev = dev;
>>>> | ~~~~~~~~~~~~^~~~~
>>>> libxlu_pci.c:51:24: note: ‘dev’ was declared here
>>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>>> | ^~~
>>>> libxlu_pci.c:30:17: error: ‘bus’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>>> 30 | pcidev->bus = bus;
>>>> | ~~~~~~~~~~~~^~~~~
>>>> libxlu_pci.c:51:19: note: ‘bus’ was declared here
>>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>>> | ^~~
>>>> libxlu_pci.c:29:20: error: ‘dom’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>>> 29 | pcidev->domain = domain;
>>>> | ~~~~~~~~~~~~~~~^~~~~~~~
>>>> libxlu_pci.c:51:14: note: ‘dom’ was declared here
>>>> 51 | unsigned dom, bus, dev, func, vslot = 0;
>>>> | ^~~
>>>> cc1: all warnings being treated as errors
>>>> make[5]: *** [/home/adminjs/xen/tools/libxl/../../tools/Rules.mk:216: libxlu_pci.o] Error 1
>>>> make[5]: *** Waiting for unfinished jobs....
>>>> make[5]: Leaving directory '/home/adminjs/xen/tools/libxl'
>>>> make[4]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:240: subdir-install-libxl] Error 2
>>>> make[4]: Leaving directory '/home/adminjs/xen/tools'
>>>> make[3]: *** [/home/adminjs/xen/tools/../tools/Rules.mk:235: subdirs-install] Error 2
>>>> make[3]: Leaving directory '/home/adminjs/xen/tools'
>>>> make[2]: *** [Makefile:72: install] Error 2
>>>> make[2]: Leaving directory '/home/adminjs/xen/tools'
>>>> make[1]: *** [Makefile:134: install-tools] Error 2
>>>> make[1]: Leaving directory '/home/adminjs/xen'
>>>> make: *** [Makefile:170: world] Error 2
>>
>> Have fun,
>> Hans