[patch] update_global_location_list my comment fix [Re: [PATCH] Fix breakpoint updates for multi-inferior]

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 08 Feb 2012 16:47:23 +0100, Pedro Alves wrote:
> We're already sorting by address first, so I'm not really sure what is
> it that's user-visible that we're trying to preserve.  Jan?

I no longer remember if

(a) I was wrongly expecting "duplicate"-marked locations are somehow visible
    in "info breakpoints".
or
(b) <the new patch comment below>.

I will check the comment change in, I hope everyone agrees with the reason.


> Even if that is still necessary, would it be ok to sort by address, then
> pspace, and only after by bkpt number?

I agree with Pedro, update_global_location_list was introduced as GDB
acceleration as the breakpoints performance became no longer bearable.

While update_global_location_list is far from perfect (it should be
incremental) we should not regress performance when it is enough to do it just
in a bit different way as Pedro suggests.


Thanks,
Jan


gdb/
2012-02-08  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* breakpoint.c (bp_location_compare): Fix comment.

--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -10589,8 +10589,9 @@ bp_location_compare (const void *ap, const void *bp)
   if (a_perm != b_perm)
     return (a_perm < b_perm) - (a_perm > b_perm);
 
-  /* Make the user-visible order stable across GDB runs.  Locations of
-     the same breakpoint can be sorted in arbitrary order.  */
+  /* Make the internal GDB representation stable across GDB runs
+     where A and B memory inside GDB can differ.  Breakpoint locations of
+     the same type at the same address can be sorted in arbitrary order.  */
 
   if (a->owner->number != b->owner->number)
     return (a->owner->number > b->owner->number)