This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] new tracepoint downloaded MI notification.


On 11/01/2012 01:59 AM, Pedro Alves wrote:
From the frontend's point of view, {number, location number} is better, and the schema "number.location_number" has been used in "=breakpoint-modified" notification. However, if we want to use {number, location number} here, we have to guarantee that the location number is an attribute of bp_location, because:
This is not a particular issue of tracepoint locations, so, if it was a problem, it
would be a problem for the existing notifications and MI commands as well.

IOW, this would need to be fixed for all those other cases that expose location
numbers, not just come up with an ad hoc solution.


I agree.


IOW, there's no good justification for deviating this notification from
existing practice.


What do you mean by "existing practice"? Is {number, location number} the "existing practise"?


>In short, if we can make location number persistent (unchanged for a given bp_location object), then {number, location number} is fine, otherwise, I'd prefer {number, address}.
{number, address} may looks stabler, but not even that is completely stable.
Change the program's code a little, recompile, reload symbols, and you'll see the
address change.  Whatever smarts you'd want the frontend to have to track
locations, GDB could do instead, once for all frontends, and better, because
  ^^^^^^^^^
IIUC, "locations" here mean location address instead of location number.

it may use properties other than the address to decided whether a new instance
of a location is logically the same as the old one (think of stap probes or static
tracepoints, where the address is really a very low target side detail; or just
consider line number instead of address).  I think all this goes hand in hand with
redesigning how GDB handles breakpoint re-setting (or rather, get rid of re-setting as is),
which will make this whole stabler locations issue better.  Keith will be going to
work on that very soon, IIUC.

FAOD, we should continue to use {number, location number}, and it requires improvement of breakpoint re-setting, correct?


--
Yao


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]