On Wed, Jan 21, 2026 at 04:24:43PM +0100, Jan Beulich wrote:
> qsort() implementations have freedom towards actions taken when two items
> compare equal. The latest with the introduction of fake "end" symbols,
> inconsistent sorting between the 1st and 2nd run can lead to extra "end"
> symbols in one of the runs, making the resulting symbol table partly
> unusable. (Note in particular that --warn-dup or --error-dup are passed
> only on the 2nd run, and only for xen.syms, and that option has the effect
> of doing a name sort ahead of doing the address sort. I.e. the inputs to
> the 2nd qsort() are pretty different between the 1st and 2nd runs.)
>
> Make the result stable by using original order to break ties.
>
> Fixes: d3b637fba31b ("symbols: arrange to know where functions end")
> Reported-by: Roger Pau Monné <[email protected]>
> Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Roger Pau Monné <[email protected]>
> ---
> I can't exclude the unreliable sorting could have other bad effects, in
> which case some much older commit would likely need referencing by Fixes:.
Lacking a more clear indicator I'm fine to use the current Fixes
reference.
Thanks, Roger.
