On 23/12/2020 16:59, Jan Beulich wrote:
> On 23.12.2020 17:53, Andrew Cooper wrote:
>> On 23/12/2020 16:05, Jan Beulich wrote:
>>> Its expansion shouldn't be tied to NDEBUG - down the road we may want to
>>> allow enabling assertions independently of CONFIG_DEBUG. Replace the few
>>> uses by a new xen_build_info() helper, subsuming gcov_string at the same
>>> time (while replacing the stale CONFIG_GCOV used there) and also adding
>>> CONFIG_UBSAN indication.
>>>
>>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>,
> Thanks.
>
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -70,6 +70,30 @@ const char *xen_deny(void)
>>> return "<denied>";
>>> }
>>>
>>> +static const char build_info[] =
>>> + "debug="
>>> +#ifdef CONFIG_DEBUG
>>> + "y"
>>> +#else
>>> + "n"
>>> +#endif
>>> +#ifdef CONFIG_COVERAGE
>>> +# ifdef __clang__
>>> + " llvmcov=y"
>>> +# else
>>> + " gcov=y"
>>> +# endif
>>> +#endif
>>> +#ifdef CONFIG_UBSAN
>>> + " ubsan=y"
>>> +#endif
>>> + "";
>>> +
>>> +const char *xen_build_info(void)
>>> +{
>>> + return build_info;
>>> +}
>> ... do we really need a function here?
>>
>> Wouldn't an extern const char build_info[] do?
> It probably would, but I wanted things to remain consistent with
> the siblings, many of which also return string literals (or
> effectively plain numbers).
The only reason they are still functions is because there was an
argument over breaking the livepatch testing on older versions of Xen,
and I got bored arguing.
I, however, don't consider this a valid reason to block improvements.
~Andrew
