Re: [PATCH] Eclair: scan the last xen-syms linking pass on Arm

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 10/7/26 11:35, Jan Beulich wrote:
> On 07.10.2026 07:45, Nicola Vetrini wrote:
>> On 2026-10-06 18:09, Dmytro Prokopchuk1 wrote:
>>> On 10/6/26 18:03, Jan Beulich wrote:
>>>> On 06.10.2026 16:23, Dmytro Prokopchuk1 wrote:
>>>>> Hiding .xen-syms.[013] assumed the almost-final image is always pass
>>>>> 2.
>>>>> On x86 LAST_LINKING_PASS is 2, so .xen-syms.2 stays visible. On Arm
>>>>> LAST_LINKING_PASS is 3 and the final image is .xen-syms.3, which was
>>>>> hidden. Pass 2 is usually only a symlink, so Eclair saw no program
>>>>> link
>>>>> and reported every translation unit as unreachable.
>>>>
>>>> When I did that work, rule 2.1 ended up clean for both ARM64-*
>>>> analysis
>>>> jobs (iirc). Upon re-checking I now see that ARM64-amd has 177
>>>> violations
>>>> (apparently that's what you talk about above), but ARM64-allcode has
>>>> none
>>>> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2916569232).
>>>>
>>>>> Stop hiding pass 3. Passes 0 and 1 remain excluded.
>>>>
>>>> This will cause scanning of both passes 2 and 3, i.e. consume more
>>>> time
>>>> and report duplicate violations when both passes are real linking
>>>> steps.
>>>> I think we want to be smarter than that, to really scan exactly once.
>>>> I
>>>> don't have a good idea just yet how to achieve that, though (and I was
>>>> wondering already when putting together the original patch).
>>>>
>>>> Jan
>>>
>>> Hmm
>>>
>>> At the moment
>>> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2917375773) I
>>> see ARM64 R2.1 violations:
>>> - 177 in AMD
>>> - 249 in allcode
>>>
>>> Anyway, we can have if-else like this (copied from
>>> automation/eclair_analysis/ECLAIR/tagging.ecl):
>>>
>>> -setq=target,getenv("XEN_TARGET_ARCH")
>>> if(string_equal(target,"x86_64"),
>>>       file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[013]$"}),
>>>       if(string_equal(target,"arm64"),
>>>           file_tag+({"xen_syms_tmp", "^xen/\\.xen-syms\\.[012]$"})
>>>       )
>>> )
>>>
>>> ^^^ test pipeline is here:
>>> https://gitlab.com/xen-project/people/dimaprkp4k/xen/-/pipelines/2918571749
>>>
>>> BR, Dmytro.
>>
>> In theory we could even generate a configuration file on the fly just
>> before invoking make. See e.g. [1] and [2]. In this way, we can
>> determine programmatically which is the linking step to consider, since
>> the logic involves some conditionals in the Makefile rules.
>
> Hmm, yes, that looks promising.
>
>> In any case
>> intercepting one more command that is just a symlink does not incur in a
>> big cost: only if the intercepted step is another linking command ~5
>> more minutes are needed.
>
> Yet that's an issue, at least as long as the analysis jobs generally
> determine pipeline overall latency. Plus with code size (almost) only ever
> growing, that time is also only going to (almost) ever grow.
>
> Jan
>
>> [1]
>> https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate_ecl.sh?ref_type=heads
>> [2]
>> https://gitlab.com/xen-project/hardware/xen/-/blob/staging/automation/eclair_analysis/ECLAIR/generate-linker-symbols.sh?ref_type=heads
>>
>>
>

Jan, Nicola

Thank you for the review.
Sending V2.

BR, Dmytro.