Re: [PATCH] coverage: update gcov info for newer versions of gcc

[Alex Bennée <alex.bennee@xxxxxxxxxx>]

Jan Beulich <jbeulich@xxxxxxxx> writes:

> On 11.09.2023 17:26, Alex Bennée wrote:
>> Jan Beulich <jbeulich@xxxxxxxx> 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