From: "Alex Bennée" <alex.bennee@linaro.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Javi Merino <javi.merino@cloud.com>,
Henry Wang <Henry.Wang@arm.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] coverage: update gcov info for newer versions of gcc
Date: Mon, 11 Sep 2023 18:43:16 +0100 [thread overview]
Message-ID: <87pm2oob08.fsf@linaro.org> (raw)
In-Reply-To: <7975f360-9608-3495-67ed-1dbfec330668@suse.com>
Jan Beulich <jbeulich@suse.com> writes:
> On 11.09.2023 17:26, Alex Bennée wrote:
>> Jan Beulich <jbeulich@suse.com> writes:
>>> On 02.09.2023 17:11, Javi Merino wrote:
>>>> --- a/xen/common/coverage/Makefile
>>>> +++ b/xen/common/coverage/Makefile
>>>> @@ -5,7 +5,9 @@ obj-y += $(call cc-ifversion,-lt,0407, \
>>>> gcc_3_4.o, $(call cc-ifversion,-lt,0409, \
>>
>> This isn't even supported, see below:
>>
>>>> gcc_4_7.o, $(call cc-ifversion,-lt,0500, \
>>>> gcc_4_9.o, $(call cc-ifversion,-lt,0700, \
>>>> - gcc_5.o, gcc_7.o))))
>>>> + gcc_5.o, $(call cc-ifversion,-lt,1000, \
>>>> + gcc_7.o, $(call cc-ifversion,-lt,1200, \
>>>> + gcc_10.o, gcc_12.o))))))
>>>
>>> This is getting unwieldy, so I think we ought to try to limit the number
>>> of different files we have. Already gcc_4_9.c and gcc_7.c specify the
>>> same GCOV_COUNTERS and differ only in the version checks (which could be
>>> combined). Therefore ...
>>
>> You may want to consider your policy on supported GCC versions. I see
>> you still support:
>>
>> * C compiler and linker:
>> - For x86:
>> - GCC 4.1.2_20070115 or later
>> - GNU Binutils 2.16.91.0.5 or later
>> or
>> - Clang/LLVM 3.5 or later
>> - For ARM 32-bit:
>> - GCC 4.9 or later
>> - GNU Binutils 2.24 or later
>> - For ARM 64-bit:
>> - GCC 5.1 or later
>> - GNU Binutils 2.24 or later
>>
>> While also having some commented out warnings because the base GCC is so old:
>>
>> CFLAGS += -Wmissing-prototypes
>> # (gcc 4.3x and later) -Wconversion -Wno-sign-conversion
>>
>> For reference QEMU's minimum GCC is 7.4
>>
>> if compiler.get_id() == 'gcc' and compiler.version().version_compare('>=7.4')
>>
>> and while our support cycle is based off distro LTS releases I have to
>> wonder do you actually need to support users building the
>> latest/greatest version of the hypervisor on ancient user-spaces with
>> old compilers?
>>
>> I think the oldest distro you have in your CI is jessie (still hanging
>> on with extended LTS support) and that uses GCC 4.9.
>>
>> I see there are various scripts to gather support status into the
>> documentation but I couldn't find a general statement on the projects
>> overall approach to supported versions of components.
>
> That's the problem - we've been intending to raise the baseline for quite
> some time, but figuring at least a rule of thumb by which to go both now
> and in the future turns out problematic.
FWIW QEMU states:
The project aims to support the most recent major version at all times
for up to five years after its initial release. Support for the
previous major version will be dropped 2 years after the new major
version is released or when the vendor itself drops support, whichever
comes first. In this context, third-party efforts to extend the
lifetime of a distro are not considered, even when they are endorsed
by the vendor (eg. Debian LTS); the same is true of repositories that
contain packages backported from later releases (e.g. Debian
backports). Within each major release, only the most recent minor
release is considered.
For the purposes of identifying supported software versions available
on Linux, the project will look at CentOS, Debian, Fedora, openSUSE,
RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship
similar software versions.
We also make some specific statements about python runtimes and optional
dependencies. Again this is perhaps easier for us as a user-space
program but it's worthwhile writing something up as a policy even if you
find you need to tweak it later. We also document our feature
deprecation policy and what has been removed.
If you want to crib anything from QEMU as an initial stab at it please
see:
https://qemu.readthedocs.io/en/master/about/index.html
(this is docs/about/ in our source tree).
>
> Jan
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
prev parent reply other threads:[~2023-09-11 17:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-02 15:11 [PATCH] coverage: update gcov info for newer versions of gcc Javi Merino
2023-09-07 14:41 ` Jan Beulich
2023-09-07 16:42 ` Javi Merino
2023-09-08 1:19 ` Henry Wang
2023-09-11 15:26 ` Alex Bennée
2023-09-11 16:05 ` Jan Beulich
2023-09-11 17:43 ` Alex Bennée [this message]
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=87pm2oob08.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Henry.Wang@arm.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=javi.merino@cloud.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.