All of lore.kernel.org
 help / color / mirror / Atom feed
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 16:26:01 +0100	[thread overview]
Message-ID: <87y1hcogg2.fsf@linaro.org> (raw)
In-Reply-To: <ce6e7abd-40ee-dd9e-b17c-10c39ca0e422@suse.com>


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.

>
>> --- /dev/null
>> +++ b/xen/common/coverage/gcc_10.c
>> @@ -0,0 +1,31 @@
>> +/*
>> + *  This code provides functions to handle gcc's profiling data format
>> + *  introduced with gcc 10.
>> + *
>> + *  For a better understanding, refer to gcc source:
>> + *  gcc/gcov-io.h
>> + *  libgcc/libgcov.c
>> + *
>> + *  Uses gcc-internal data definitions.
>> + */
>> +
>> +#include "gcov.h"
>> +
>> +#if GCC_VERSION < 100000 || GCC_VERSION > 120000
>> +#error "Wrong version of GCC used to compile gcov"
>> +#endif
>> +
>> +#define GCOV_COUNTERS 8
>> +#define GCOV_UNIT_SIZE 1
>> +
>> +#include "gcc_4_7.c"
>
> ... this could simply re-use gcc_4_7.c directly, with just the version
> check there suitably tweaked.
>
>> --- a/xen/common/coverage/gcc_4_7.c
>> +++ b/xen/common/coverage/gcc_4_7.c
>> @@ -27,6 +27,7 @@
>>  #  error "Wrong version of GCC used to compile gcov"
>>  # endif
>>  #define GCOV_COUNTERS 8
>> +#define GCOV_UNIT_SIZE 1
>>  #endif
>
> If further this became a separate #ifdef, ...
>
>> --- a/xen/common/coverage/gcc_4_9.c
>> +++ b/xen/common/coverage/gcc_4_9.c
>> @@ -19,6 +19,7 @@
>>  #endif
>>  
>>  #define GCOV_COUNTERS 9
>> +#define GCOV_UNIT_SIZE 1
>>  
>>  #include "gcc_4_7.c"
>>  
>> --- a/xen/common/coverage/gcc_5.c
>> +++ b/xen/common/coverage/gcc_5.c
>> @@ -19,6 +19,7 @@
>>  #endif
>>  
>>  #define GCOV_COUNTERS 10
>> +#define GCOV_UNIT_SIZE 1
>>  
>>  #include "gcc_4_7.c"
>>  
>
> ... touching these two files could be avoided altogether.
>
> Henry - afaict this was submitted after the feature submission deadline,
> so you may want to consider giving it an exception.
>
> Jan


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  parent reply	other threads:[~2023-09-11 15:52 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 [this message]
2023-09-11 16:05     ` Jan Beulich
2023-09-11 17:43       ` Alex Bennée

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=87y1hcogg2.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.