Re: [PATCH] x86/mm: compile out __set_fixmap_x() when not needed

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.11.2026 11:50, Nicola Vetrini wrote:
> On 2026-11-09 10:04, Jan Beulich wrote:
>> On 07.11.2026 08:23, Nicola Vetrini wrote:
>>> On 2026-11-03 12:28, Jan Beulich wrote:
>>>> On 03.11.2026 10:42, Jan Beulich wrote:
>>>>> Only HYPERV_GUEST has a need for an executable fixmap, so with that
>>>>> option
>>>>> unset __set_fixmap_x() (and l1_fixmap_x[] in turn) is unreachable.
>>>>> Address
>>>>> this Misra rule 2.1 violation by introduction ofa new FIXMAP_X 
>>>>> Kconfig
>>>>> setting.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>> ---
>>>>> Why is __set_fixmap_x() not found by Eclair as a rule 2.1 violation 
>>>>> in
>>>>> the
>>>>> x86_64-amd job?
>>>>
>>>> Same question actually for both functions converted to static by [1].
>>>> This
>>>> apparently being a wider problem, are we (again / still) having an
>>>> issue
>>>> with the scanning of the linking steps?
>>>>
>>>> Jan
>>>>
>>>> [1] 
>>>> https://lists.xen.org/archives/html/xen-devel/2026-10/msg01537.html
>>>
>>> It was a Xen project decision not to consider for R2.1 functions that
>>> are never referenced: you can see in
>>> "automation/eclair_analysis/ECLAIR/deviations.ecl". Of course that is
>>> reversible and I am in favour of not hiding those violations, but the
>>> rationale for the justification that was given is that the compiler 
>>> will
>>> indeed DCE those:
>>>
>>>     * - R2.1
>>>       - The compiler implementation guarantees that the unreachable 
>>> code
>>> is
>>>         removed. Constant expressions and unreachable branches of if 
>>> and
>>> switch
>>>         statements are expected.
>>>       - Tagged as `safe` for ECLAIR.
>>
>> For the cases at hand (and then likely many more) the compiler doesn't 
>> DCE
>> anything. Imo the wording here is completely bogus. It may say "If the
>> compiler implementation guarantees ..." Which it might do for static
>> functions, but aiui without LTO it never will for non-static ones.
>>
> 
> I'm not saying the configuration is good as is. Ideally that should be 
> removed or restricted to static functions and the likely newly present 
> violations triaged.
> 
>> Then I'm also puzzled by the deviations.ecl entry:
>>
>> -doc_begin="The compiler implementation guarantees that the unreachable 
>> code is removed.
>> Constant expressions and unreachable branches of if and switch 
>> statements are expected."
>> -config=MC3A2.R2.1,+reports={safe,"first_area(^.*has an 
>> invariantly.*$)"}
>> -config=MC3A2.R2.1,+reports={safe,"first_area(^.*incompatible with 
>> labeled statement$)"}
>> -doc_end
>>
>> First - these are two different deviations, and hence imo should be two
>> separate entries. More important here though is that I can't connect 
>> the
>> two config= lines to the deviation of unreferenced non-static 
>> functions.
>> There's nothing "... has an invariantly ..."  or "... incompatible with
>> labeled statement ..." there? How would the full diagnostic for an
>> unreferenced global function (or data item) look like?
> 
> These two have nothing do do with functions never referenced indeed: the 
> rule is about unreachable code in general, of which functions that are 
> never called is just a subcase.

Yet then in your earlier mail which part of deviations.ecl did you refer
to?

Jan