Hi,

While working on the target-side condition evaluation patch, i stumbled 
upon the strange situation where GDB had more than a single "inserted" 
location in a list with multiple duplicate locations.

Further investigation showed that the logic for finding the first 
inserted location at a specific address does not work when multiple 
inferiors are being debugged. This code is inside 
update_global_location_list (...).

This is partly because we expect the list of locations to be sorted by 
breakpoint numbers and addresses.

Suppose we're going through locations at address FOO, and we already 
defined the "first" for that set of locations. When a location does not 
match the "first" location of that address, we then assume we've gone 
past the locations at address FOO. This is correct for single inferiors.

Now, consider a multi-inferior scenario and breakpoints with locations 
on multiple inferiors. The code will fail to match two locations due to 
the difference between the locations' program spaces, thus failing to 
mark duplicate locations correctly.

This patch solves this by updating the locations one program space at a 
time, thus preventing multiple insertions of the same location.

This bug shows up when doing multi-inferior debugging in GDBServer. You 
will notice GDB sending multiple insert/remove requests for the same 
address.

OK?

Luis