On Mon, 21 Feb 2022 at 17:06, Alex Bennée <alex.ben...@linaro.org> wrote: > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On Thu, 10 Feb 2022 at 11:30, Alex Bennée <alex.ben...@linaro.org> wrote: > >> > >> The previous numbers were a guess at best and rather arbitrary without > >> taking into account anything that might be loaded. Instead of using > >> guesses based on the state of registers implement a new function that: > >> > >> a) scans the MemoryRegions for the largest RAM block > >> b) iterates through all "ROM" blobs looking for the biggest gap > >> > >> The "ROM" blobs include all code loaded via -kernel and the various > >> -device loader techniques. > >> > >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > >> Cc: Andrew Strauss <astraus...@gmail.com> > >> Cc: Keith Packard <kei...@keithp.com> > >> Message-Id: <20210601090715.22330-1-alex.ben...@linaro.org> > >> > > > > > >> +/* > >> + * Sort into address order. We break ties between rom-startpoints > >> + * and rom-endpoints in favour of the startpoint, by sorting the 0->1 > >> + * transition before the 1->0 transition. Either way round would > >> + * work, but this way saves a little work later by avoiding > >> + * dealing with "gaps" of 0 length. > >> + */ > >> +static gint sort_secs(gconstpointer a, gconstpointer b) > >> +{ > >> + RomSec *ra = (RomSec *) a; > >> + RomSec *rb = (RomSec *) b; > >> + > >> + if (ra->base == rb->base) { > >> + return ra->se - rb->se; > >> + } > >> + return ra->base > rb->base ? 1 : -1; > >> +} > > > > This sort comparator still doesn't report the equality > > case as actually equal. > > When ra->se and rb->se are the same it returns 0. Is that not what you want?
Oops, yes it does. I misread it because I was expecting it to be structured differently. (AFAIK there is no "standard" way to structure a comparator-function that works with multiple fields, so the way you have it is fine.) -- PMM