[PATCH roland/objcopy-merge-notes-qsort] Fix objcopy --merge-notes dependency on qsort implementation behavior.

[Nick Clifton]

Hi Roland,

> The comparison function used in the sort to prepare to merge
> .gnu.build.attributes notes returns different results for a comparison
> of overlapping ranges depending on the order of the arguments, i.e.
> compare(a, b) == -compare(b, a) does not hold.

Oops - that is embarrassing.


> This change makes the behavior consistent with what happens on Linux,
> which is what the test suite expects.  However, note that this appears
> to contradict the behavior described in the comments: In the test case
> there is a func entry (result of merging two adjacent func entries
> under rule 2b) wholly contained by the range of an OPEN entry (result
> of merging two adjacent OPEN entries under rule 2b).  The comments
> seem to say that this func entry should have been removed under rule
> 2a (fully covered range, regardless of type).  This is the behavior I
> saw (breaking the test suite) on the macOS build before this change.
> If that is indeed the correct behavior,

It is.  Or at least that is what should happen for an optimal merge.
It is not an error for the notes not to be merged, it is just a case
that an opportunity for merging was missed.


> then some different fix is
> needed to achieve that and the test suite needs to change its
> expectations

If you would like to look into this and suggest a patch then please
do.  Otherwise I will add it to my list of things to do.


> (though certainly a fix like this one is also
> appropriate--the compare(a,b) == -compare(b, a) invariant should
> always hold for any qsort callback!).

> Ok for trunk and 2.34? 

Yes for both - please apply.

Cheers
  Nick