Hi,

This patch handles GDB-specific changes to support stub-side breakpoint 
conditions.

It adds machinery to detect locations that had their conditions changed. 
In case conditions change for any location, such changes need to be 
reported to/synched with the stub for evaluation, or else we may be left 
with a stub evaluating old conditionals.

This machinery works by marking locations modified through the 
"condition_changed" field. Conditions change whenever we create a new 
location, use the "condition" command or delete an old duplicate 
location. Furthermore, if a location at addr 0xdeadbeef had its 
condition modified, all duplicate locations at 0xdeadbeef are marked 
modified as well.

The modification detection takes place inside 
update_global_location_list (...). By calling 
force_breakpoint_reinsertion (...), we mark every location at address 
0xdeadbeef as modified. When consolidating the final updated list of 
locations, we detect these locations and mark the non-duplicate location 
at 0xdeafbeef as "needs_update".

The "needs_update" field is used during breakpoint insertion. It forces 
insertion of breakpoints even if they are marked as inserted already.

Now that we have information about locations that we should reinsert in 
the target, we proceed to build a list of hex-encoded agent expressions.

At this point, if any conditional expressions fail to parse to a valid 
agent expression, we assume that the conditions will be evaluated on 
GDB's side. Thus we don't send the conditions to the stub. Otherwise, we 
proceed to insert the breakpoints and the remote code now attaches the 
hex-encoded expressions to the z0/z1 packet.

Regarding always-inserted mode, if it is "on" we must send condition 
changes right away, or else the target will potentially miss breakpoint 
hits. If always-inserted is "off", this isn't too critical, so we just 
wait for the insertion call to send all the conditions to the stub. We 
will remove them when stopping anyway.

Other changes include handling of the new "condition-evaluation" 
breakpoint subcommand and showing the condition-evaluation mode in "info 
break" if it is "stub". We do not show the evaluation mode if it is "gdb".

I ran the testsuite and had no additional failures.

The location conditional modification detection machinery should be 
non-functional if GDB is doing all the condition evaluation work on its own.

I'd like to hear about the change to "info break" and also the way we 
should pass conditions down to the stub.  Currently i'm adding the agent 
expressions to a condition list in the target info field of bp locations.

Comments are much appreciated.

Luis
lgustavo@codesourcery.com