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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.10.2026 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).
> 
> At the moment
> (https://gitlab.com/xen-project/hardware/xen/-/pipelines/2917375773) I
> see ARM64 R2.1 violations:
> - 177 in AMD
> - 249 in allcode

Which demonstrates how variable the situation is.

> 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]$"})
>      )
> )

Ah, yes, perhaps. Yet there isn't any if-else needed here, is there?
tagging.ecl also uses two simply if()-s afaics. (Excluding .xen-syms.3
on x86 is pointless. There's no 3rd pass there just yet, and once one
would need adding, we'd want to similarly scan that rather than the
potentially no-op pass 2.)

The thing that continues to worry me with this is: This way we have a
connection between the build machinery under xen/ and the patterns
here, which need keeping in sync manually. That's going to be pretty
easy to miss.

Jan