Re: RFA: Breakpoint infrastructure cleanups [0/8]

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Elizabeth Chastain]

Michael Snyder writes:
> Disassemble doesn't share the same syntax/semantics (decode_line_1);
> it has its own (I think?) -- but you're right, it's another command
> that takes a source location and "translates" it into a target
> location.

Yeah, we are in agreement here.  My point is that there are
"source" locations (or whatever we want to call them)
and "target" locations (or whatever we want to call them).
We have to go back to the manual and the design stage and separate
all these out as separate concepts.

mec>   (gdb) break *0x12345678
ms> Now I don't follow you.  "*0x12345678" isn't a source address.
ms> Is it?

Ah, I am just saying that this is a user command that is oriented
towards "target" locations.  So we can't just hide the concept
of "target" location from people, because that concept is already
present in the input language.

Michael C

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Michael Elizabeth Chastain wrote:
> Michael Snyder writes:
> 
>>Disassemble doesn't share the same syntax/semantics (decode_line_1);
>>it has its own (I think?) -- but you're right, it's another command
>>that takes a source location and "translates" it into a target
>>location.
> 
> 
> Yeah, we are in agreement here.  My point is that there are
> "source" locations (or whatever we want to call them)
> and "target" locations (or whatever we want to call them).
> We have to go back to the manual and the design stage and separate
> all these out as separate concepts.

OK, yes, agreed.

> mec>   (gdb) break *0x12345678
> ms> Now I don't follow you.  "*0x12345678" isn't a source address.
> ms> Is it?
> 
> Ah, I am just saying that this is a user command that is oriented
> towards "target" locations.  So we can't just hide the concept
> of "target" location from people, because that concept is already
> present in the input language.

Oh yes, of course.  I don't mean to make the concept go away,
just not to reveal it (if avoidable) when the user didn't ask.
Just as the user can get the value of a variable without being
told the variable's location -- but can still obtain the location
if desired.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Jim Ingham]

On Oct 16, 2003, at 9:17 AM, gdb-patches-digest-help@sources.redhat.com 
wrote:

>>>> And MI? what should we do there? the same 3 cases occur.  I would
>>>> think that MI could just tell the gui everything every time, and 
>>>> then
>>>> the GUI could decide to display what it wants.
>>>
>>> Probably.
>>>
>>>> However that's a lot
>>>> of information sent back and forth, maybe for no real advantage. So
>>>> maybe a two-tier command set is needed there too.
>>>
>>> Yes, probably.
>>
>> These make sense to me also.
>>
>
> I'd like to hear from MI users otherwise we'll be designing in a 
> vacuum.
> I'll send something to the eclipse folks.
>
>

I think in all cases the UI will want to know about the multiple hits.

One case that would be very useful is a single breakpoint that turns 
into many logically distinct entities.  For instance, breaking on a 
file & line in a template function or class method turns into 
breakpoints on all the instantiations of that template function/method. 
  In this case the GUI really would be interested in this, since it 
would be useful to display these choices to the user and have her pick 
which ones she actually wants.

The other is where the multiple breakpoints are not really distinct.  
An example of this is breaking on an inlined function.  Without 
expanding inlined calls in the source view of the call sites, knowing 
where all the breakpoints are in source view is not terribly helpful.  
But if somebody switches to Assembly view, we had better show them the 
breakpoints that have been set or they will get very confused...

So I think we do need them.

Our experience with MI is that as long as the information dump is not 
too large, multiple round trips are more expensive than lots of info.  
Parsing the MI output is pretty quick.  I bet if we start getting 
~1000's of breakpoints the time gdb spends finding all the instances 
will swamp the time it takes to ship them across the pipe...  So my 
guess is that doing it simply and just telling the user about all the 
breakpoints as they are set is okay.

The one thing we do need to be careful about is to not reset all the 
breakpoints in all the shared libraries each time a new one is loaded.  
This is the current gdb behavior, but it will quickly get very 
inefficient as the number of shared libraries & breakpoints therein 
increase.  It is pretty easy to get around this with a little judicial 
hacking, however.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Jim Ingham wrote:
> It is pretty easy to get around this with a little judicial 
> hacking, however.

That sounds like the kind that'll get you 5 to 20.   ;-)

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Jim Ingham]

I would be careful to stay away from turning "logically" specified 
breakpoints (by which I mean specified on function name or source 
location) into addresses to the user.  Even between rerunnings of the 
same executable a library's load address can shift, causing the address 
to move.  gdb can probably still make the equivalency between the 
breakpoints - most slides are rigid, for instance.  But the address 
doesn't show this.  I would use something simble like 5a, 5b or 
whatever...

Jim

On Oct 16, 2003, at 9:17 AM, gdb-patches-digest-help@sources.redhat.com 
wrote:

>> From: Elena Zannoni <ezannoni@redhat.com>
>> Date: Thu, 16 Oct 2003 10:32:57 -0400
>>
>> Just occurred to me that maybe the user sometimes would want to set a
>> breakpoint in just one particular instance of an inlined function, we
>> should still allow that.
>
> How about the following?
>
> (gdb) break inline_foo
> Breakpoint 5 set at inline_foo, which has multiple locations.
> Say "info breakpoint 5" for more details.
> (gdb) info break 5
> Num Type          Enb Address    What
> 5   sw breakpoint  y  0x8040222  inlined into foo
> 5   sw breakpoint  y  0x8040822  inlined into bar
> 5   sw breakpoint  y  0x8040852  inlined into boring_loop
> (gdb) delete 5 *0x8040852
>
>> I.e. should setting the multiple breakpoints
>> be the default?
>
> I think this is the best default, yes.
>
> Alternatively, we could show all possible addresses where the
> requested breakpoint coulod be set and ask the user to select which
> ones she wants, like this:
>
> (gdb) break inline_foo
> Function inline_foo is inlined into multiple locations:
>   Address    Location
>   0x8040222  inlined into foo
>   0x8040822  inlined into bar
>   0x8040852  inlined into boring_loop
> Please use "break *address" to set breakpoints at one or more of these
> (gdb) break *0x8040822 *0x8040822
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> From: Jim Ingham <jingham@apple.com>
> Date: Thu, 16 Oct 2003 12:03:11 -0700
> 
> I would be careful to stay away from turning "logically" specified 
> breakpoints (by which I mean specified on function name or source 
> location) into addresses to the user.  Even between rerunnings of the 
> same executable a library's load address can shift, causing the address 
> to move.  gdb can probably still make the equivalency between the 
> breakpoints - most slides are rigid, for instance.  But the address 
> doesn't show this.

I didn't say that GDB should _store_ the address that the user types
in order to disambiguate the place where to put the trap.  It is just
a means to tell GDB which of the possibilities to take.  It has an
advantage of being natural to GDB users, since you can put a
breakpoint on a specific address in current versions of GDB.

After the trap was put, if GDB can solve the problem of moving
addresses (as it does that now), it can also solve the problem we are
discussing here.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Jim Ingham]

Yeah, but if I told gdb to set breakpoints at *0x....., and sometimes 
those breakpoints would just stick at that address, and other times 
they would move around, that would be disconcerting to me.  If the 
breakpoint is not going to be at a fixed address, we oughtn't to refer 
to it as if it were.

Jim

On Oct 16, 2003, at 11:59 PM, Eli Zaretskii wrote:

>> From: Jim Ingham <jingham@apple.com>
>> Date: Thu, 16 Oct 2003 12:03:11 -0700
>>
>> I would be careful to stay away from turning "logically" specified
>> breakpoints (by which I mean specified on function name or source
>> location) into addresses to the user.  Even between rerunnings of the
>> same executable a library's load address can shift, causing the 
>> address
>> to move.  gdb can probably still make the equivalency between the
>> breakpoints - most slides are rigid, for instance.  But the address
>> doesn't show this.
>
> I didn't say that GDB should _store_ the address that the user types
> in order to disambiguate the place where to put the trap.  It is just
> a means to tell GDB which of the possibilities to take.  It has an
> advantage of being natural to GDB users, since you can put a
> breakpoint on a specific address in current versions of GDB.
>
> After the trap was put, if GDB can solve the problem of moving
> addresses (as it does that now), it can also solve the problem we are
> discussing here.
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Elizabeth Chastain]

My two cents:

It's not just breakpoints.  What happens when the user types:

  (gdb) disassemble Foo::Foo

Also, here is a use case to consider:

  (gdb) break *0x12345678

gdb has this notion that one source address corresponds to one
object-code address, but now it's one source address corresponds
to N object-code addresses.

Michael C

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Michael Elizabeth Chastain wrote:
> My two cents:
> 
> It's not just breakpoints.  What happens when the user types:
> 
>   (gdb) disassemble Foo::Foo

That's true -- or taking a step back, we currently use one semantics
(and syntax) for all commands that take a source location as an argument
(basicly break and list).  Are we going to 'break' that?  I think it's
OK to do so, because for list, you really do mean a source location,
whereas for break, you may mean many target locations.

Disassemble doesn't share the same syntax/semantics (decode_line_1);
it has its own (I think?) -- but you're right, it's another command
that takes a source location and "translates" it into a target
location.

> Also, here is a use case to consider:
> 
>   (gdb) break *0x12345678
> 
> gdb has this notion that one source address corresponds to one
> object-code address, but now it's one source address corresponds
> to N object-code addresses.

Now I don't follow you.  "*0x12345678" isn't a source address.
Is it?  Unles you've got multiple memory address spaces or
something... something more deviant than just Harvard, which
we already know how to handle.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Jim Ingham]

On Oct 9, 2003, at 12:49 PM, gdb-patches-digest-help@sources.redhat.com 
wrote:

> From: Michael Snyder <msnyder@redhat.com>
> Date: October 9, 2003 12:33:14 PM PDT
> To: Daniel Jacobowitz <drow@mvista.com>
> Cc: gdb-patches@sources.redhat.com
> Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8]
>
>
> Daniel Jacobowitz wrote:
>> On Thu, Oct 09, 2003 at 08:10:46AM +0200, Eli Zaretskii wrote:
>>>> Date: Wed, 8 Oct 2003 15:05:02 -0400
>>>> From: Daniel Jacobowitz <drow@mvista.com>
>>>>
>>>>> (gdb) info break
>>>>> Num Type           Disp Enb Address    What
>>>>> 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at 
>>>>> hello.c:8
>>>>>                            0x08048364 in foo::foo (not-in-charge) 
>>>>> at hello.c:8
>>>>> (gdb)
>>>>
>>>> Here's the problem that I see.
>>>>
>>>> For foo::foo, there are two of these things.  Having them both in 
>>>> the
>>>> list would be nice.  Really nice.
>>>>
>>>> For inline_accessor_fn there are 3.8 million.  In addition to 
>>>> needing
>>>> to do a whole lot of work on GDB internals before we could survive 
>>>> this
>>>> (memory usage; ptrace thrashing inserting and removing them; linked
>>>> lists of breakpoints; and that's just the beginning) this has some
>>>> severe user interface implications.  We don't want to print out all
>>>> those addresses by default!
>>>>
>>>> I'm open to suggestions on how to deal with this.
>>>
>>> How about a switch to "info break"?  By default, show only the
>>> in-charge breakpoint, but if the user says "info break -all" or some
>>> such, show the other 3.8 million minus one.
>>> From a user interface perspective, I got a really strong negative
>> pushback the last time I tried to add a switch to any GDB command.
>
> OK, how about modeling after "info reg" vs. "info all-reg"?
> Giving us "info break" and a new "info all-break".
>

This seems a little odd, because then if I want to see the 
implementations for one user breakpoint - like where were all the 
template instantiations for a file:line breakpoint in a C++ template 
(*) then I say:

info all-break 5

Not sure what a better word is but "all" doesn't convey that you want 
more details about each...  Maybe "full" is better, like "info 
break-full"?

Jim

(*) Yes, I know that we can't do this yet, but...
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

This is a series of eight patches which begin to clean up our infrastructure
for tracking breakpoints.  More specifically, I chose to split the struct
breakpoint into two: one which is logically associated with the user's
"break" command, and one which is logically associated with an insertable
breakpoint.  The general idea is that the mapping should be one-to-many
eventually.  Right now it isn't and there's a long way to go before we can
get there, but this is a first step.

This will make it simpler to have, for instance, a breakpoint on both the
in-charge and not-in-charge constructors without bothering the user with
that detail.  Similarly (eventually!) for copies of an inlined function, or
multiple copies of an executed line.  This is a bit of a ways in the future
but I'm working on it.

On the infrastructure side we will be able to have an "impl_breakpoint"
(short for implementation; better naming ideas?) for each location we are
watching using hardware watchpoints.  This will simplify a lot of code.  It
will also eventually become easier to object-orient our breakpoints.

Except for a couple of minor bug fixes where noted, these patches change
nothing.  They use the assumption that every breakpoint has exactly one
implementation breakpoint.  After they've been applied, it's easy to find
conceptual layering issues; most (not all) references to b->impl are
potential problems, and some references to bpt->owner are also.  I've
converted functions which operated primarily on the impl to accept impl
breakpoint arguments instead of user breakpoint arguments.  Many of the
remaining layering issus deal with printing the address of a breakpoint; I'd
love to hear what other people think we should do for breakpoints with
multiple addresses.  Just say multiple, and provide a maint (or info)
command to look at them?

The actual patches will follow in separate messages.  Thoughts?  Comments on
the overall approach?  OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Daniel Jacobowitz writes:
 > This is a series of eight patches which begin to clean up our infrastructure
 > for tracking breakpoints.  More specifically, I chose to split the struct
 > breakpoint into two: one which is logically associated with the user's
 > "break" command, and one which is logically associated with an insertable
 > breakpoint.  The general idea is that the mapping should be one-to-many
 > eventually.  Right now it isn't and there's a long way to go before we can
 > get there, but this is a first step.
 > 

This is certainly the right direction. We have discussed this in very
general terms (I believe at the gcc conference), but I don't remember
a discussion on the gdb lists. Since this seems quite a big rewrite (I
am not sure, I just saw all this stuff appearing at once), how about
using the branching approach? It has worked well for a few features now.

elena


 > This will make it simpler to have, for instance, a breakpoint on both the
 > in-charge and not-in-charge constructors without bothering the user with
 > that detail.  Similarly (eventually!) for copies of an inlined function, or
 > multiple copies of an executed line.  This is a bit of a ways in the future
 > but I'm working on it.
 > 
 > On the infrastructure side we will be able to have an "impl_breakpoint"
 > (short for implementation; better naming ideas?) for each location we are
 > watching using hardware watchpoints.  This will simplify a lot of code.  It
 > will also eventually become easier to object-orient our breakpoints.
 > 
 > Except for a couple of minor bug fixes where noted, these patches change
 > nothing.  They use the assumption that every breakpoint has exactly one
 > implementation breakpoint.  After they've been applied, it's easy to find
 > conceptual layering issues; most (not all) references to b->impl are
 > potential problems, and some references to bpt->owner are also.  I've
 > converted functions which operated primarily on the impl to accept impl
 > breakpoint arguments instead of user breakpoint arguments.  Many of the
 > remaining layering issus deal with printing the address of a breakpoint; I'd
 > love to hear what other people think we should do for breakpoints with
 > multiple addresses.  Just say multiple, and provide a maint (or info)
 > command to look at them?
 > 
 > The actual patches will follow in separate messages.  Thoughts?  Comments on
 > the overall approach?  OK?
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> This is certainly the right direction. We have discussed this in very
> general terms (I believe at the gcc conference), but I don't remember
> a discussion on the gdb lists. Since this seems quite a big rewrite (I
> am not sure, I just saw all this stuff appearing at once), how about
> using the branching approach? It has worked well for a few features now.

Honestly, yes.  As core maintainers we should be willing to do as we ask.

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 03:04:09PM -0400, Andrew Cagney wrote:
> >This is certainly the right direction. We have discussed this in very
> >general terms (I believe at the gcc conference), but I don't remember
> >a discussion on the gdb lists. Since this seems quite a big rewrite (I
> >am not sure, I just saw all this stuff appearing at once), how about
> >using the branching approach? It has worked well for a few features now.
> 
> Honestly, yes.  As core maintainers we should be willing to do as we ask.

I don't ask for people to use branches, because it's a bloody nuisance. 
Once all patches have gone onto a branch, reproducing a series of
logically contained patches that are small enough to be acceptable to
the GDB Gods is an additional week or month of work.  I prefer when
possible to do work in increments, on mainline.

Having been asked twice to use a branch I'll investigate it.  Not for
these patches, however, which are designed to be non-behavior-changing
cleanups.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[David Carlton]

On Wed, 8 Oct 2003 15:07:26 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> I don't ask for people to use branches, because it's a bloody
> nuisance.  Once all patches have gone onto a branch, reproducing a
> series of logically contained patches that are small enough to be
> acceptable to the GDB Gods is an additional week or month of work.
> I prefer when possible to do work in increments, on mainline.

I don't see any reason for a branch here.  The extra work is a pain,
and the patches have already started generating a nice amount of
productive discussion, more (I suspect) than they would have gotten if
they were on a branch.  Incremental development on mainline is good;
branching might be appropriate if you're trying to chose between two
choices and undoing the wrong choice would be a fair amount of work,
or if you can't figure out how to do something incrementally, but I
don't think that's the situation with these patches.

David Carlton
carlton@kealia.com

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

David Carlton writes:
 > On Wed, 8 Oct 2003 15:07:26 -0400, Daniel Jacobowitz <drow@mvista.com> said:
 > 
 > > I don't ask for people to use branches, because it's a bloody
 > > nuisance.  Once all patches have gone onto a branch, reproducing a
 > > series of logically contained patches that are small enough to be
 > > acceptable to the GDB Gods is an additional week or month of work.
 > > I prefer when possible to do work in increments, on mainline.
 > 
 > I don't see any reason for a branch here.  The extra work is a pain,
 > and the patches have already started generating a nice amount of
 > productive discussion, more (I suspect) than they would have gotten if
 > they were on a branch.  Incremental development on mainline is good;
 > branching might be appropriate if you're trying to chose between two
 > choices and undoing the wrong choice would be a fair amount of work,
 > or if you can't figure out how to do something incrementally, but I
 > don't think that's the situation with these patches.
 > 
 > David Carlton
 > carlton@kealia.com


FWIW
Some background on this seems to be in these threads:

(more detailed here)
http://sources.redhat.com/ml/gdb/2003-03/msg00349.html

(vaguely here)
http://sources.redhat.com/ml/gdb-patches/2003-03/msg00482.html

I thought there was some other discussion but I cannot find it.

elena

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> On Wed, Oct 08, 2003 at 03:04:09PM -0400, Andrew Cagney wrote:
> 
>> >This is certainly the right direction. We have discussed this in very
>> >general terms (I believe at the gcc conference), but I don't remember
>> >a discussion on the gdb lists. Since this seems quite a big rewrite (I
>> >am not sure, I just saw all this stuff appearing at once), how about
>> >using the branching approach? It has worked well for a few features now.
> 
>> 
>> Honestly, yes.  As core maintainers we should be willing to do as we ask.
> 
> 
> I don't ask for people to use branches, because it's a bloody nuisance. 
> Once all patches have gone onto a branch, reproducing a series of
> logically contained patches that are small enough to be acceptable to
> the GDB Gods is an additional week or month of work.  I prefer when
> possible to do work in increments, on mainline.

I agree, instead prefering a steady sequence of incremental change.

> Having been asked twice to use a branch I'll investigate it.  Not for
> these patches, however, which are designed to be non-behavior-changing
> cleanups.

Thanks for clarifying this.

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> This is a series of eight patches which begin to clean up our infrastructure
> for tracking breakpoints.  More specifically, I chose to split the struct
> breakpoint into two: one which is logically associated with the user's
> "break" command, and one which is logically associated with an insertable
> breakpoint.  The general idea is that the mapping should be one-to-many
> eventually.  Right now it isn't and there's a long way to go before we can
> get there, but this is a first step.
>
> This will make it simpler to have, for instance, a breakpoint on both the
> in-charge and not-in-charge constructors without bothering the user with
> that detail.  Similarly (eventually!) for copies of an inlined function, or
> multiple copies of an executed line.  This is a bit of a ways in the future
> but I'm working on it.

This sounds really great.

When you think about what actually is happening in the debuggee, the
mapping is actually many-to-many, since you can have multiple user
breakpoints at the same address.  Not that this affects your data
structures --- just an observation.

> On the infrastructure side we will be able to have an "impl_breakpoint"
> (short for implementation; better naming ideas?) for each location we are
> watching using hardware watchpoints.  This will simplify a lot of code.  It
> will also eventually become easier to object-orient our breakpoints.

How about "user breakpoints" and "machine breakpoints"?

> Except for a couple of minor bug fixes where noted, these patches change
> nothing.  They use the assumption that every breakpoint has exactly one
> implementation breakpoint.  After they've been applied, it's easy to find
> conceptual layering issues; most (not all) references to b->impl are
> potential problems, and some references to bpt->owner are also.  I've
> converted functions which operated primarily on the impl to accept impl
> breakpoint arguments instead of user breakpoint arguments.  Many of the
> remaining layering issus deal with printing the address of a breakpoint; I'd
> love to hear what other people think we should do for breakpoints with
> multiple addresses.  Just say multiple, and provide a maint (or info)
> command to look at them?

I think 'info break' should list the addresses.  I don't know how this
should fit into the MI format, but it ought to be MI that changes,
rather than omitting useful behavior.

In my ideal world, you'd get an explanation for why each address was
chosen, when it's not obvious:

(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
                            0x08048364 in foo::foo (not-in-charge) at hello.c:8
(gdb) 

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Joel Brobecker]

> How about "user breakpoints" and "machine breakpoints"?

"How Debuggers Work" define "logical" and "physical". But I really
prefer Jim's proposal, especially the "user" one, as it sounds clearer
than "logical".

> In my ideal world, you'd get an explanation for why each address was
> chosen, when it's not obvious:
> 
> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
>                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
> (gdb) 

This looks very good to me. (although it's also fine  not to provide the
explanation, it's not as important as seeing all the machine breakpoints).

-- 
Joel

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 01:05:34PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > This is a series of eight patches which begin to clean up our infrastructure
> > for tracking breakpoints.  More specifically, I chose to split the struct
> > breakpoint into two: one which is logically associated with the user's
> > "break" command, and one which is logically associated with an insertable
> > breakpoint.  The general idea is that the mapping should be one-to-many
> > eventually.  Right now it isn't and there's a long way to go before we can
> > get there, but this is a first step.
> >
> > This will make it simpler to have, for instance, a breakpoint on both the
> > in-charge and not-in-charge constructors without bothering the user with
> > that detail.  Similarly (eventually!) for copies of an inlined function, or
> > multiple copies of an executed line.  This is a bit of a ways in the future
> > but I'm working on it.
> 
> This sounds really great.
> 
> When you think about what actually is happening in the debuggee, the
> mapping is actually many-to-many, since you can have multiple user
> breakpoints at the same address.  Not that this affects your data
> structures --- just an observation.

Right.  At the moment we use the duplicate flag to handle this; it may
be necessary to do it differently in the future, but it's hard to say.
I want to get a little further before I think about that.

> > On the infrastructure side we will be able to have an "impl_breakpoint"
> > (short for implementation; better naming ideas?) for each location we are
> > watching using hardware watchpoints.  This will simplify a lot of code.  It
> > will also eventually become easier to object-orient our breakpoints.
> 
> How about "user breakpoints" and "machine breakpoints"?

I like it.

> > Except for a couple of minor bug fixes where noted, these patches change
> > nothing.  They use the assumption that every breakpoint has exactly one
> > implementation breakpoint.  After they've been applied, it's easy to find
> > conceptual layering issues; most (not all) references to b->impl are
> > potential problems, and some references to bpt->owner are also.  I've
> > converted functions which operated primarily on the impl to accept impl
> > breakpoint arguments instead of user breakpoint arguments.  Many of the
> > remaining layering issus deal with printing the address of a breakpoint; I'd
> > love to hear what other people think we should do for breakpoints with
> > multiple addresses.  Just say multiple, and provide a maint (or info)
> > command to look at them?
> 
> I think 'info break' should list the addresses.  I don't know how this
> should fit into the MI format, but it ought to be MI that changes,
> rather than omitting useful behavior.
> 
> In my ideal world, you'd get an explanation for why each address was
> chosen, when it's not obvious:
> 
> (gdb) info break
> Num Type           Disp Enb Address    What
> 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
>                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
> (gdb) 

Here's the problem that I see.

For foo::foo, there are two of these things.  Having them both in the
list would be nice.  Really nice.

For inline_accessor_fn there are 3.8 million.  In addition to needing
to do a whole lot of work on GDB internals before we could survive this
(memory usage; ptrace thrashing inserting and removing them; linked
lists of breakpoints; and that's just the beginning) this has some
severe user interface implications.  We don't want to print out all
those addresses by default!

I'm open to suggestions on how to deal with this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> On the infrastructure side we will be able to have an "impl_breakpoint"
>> > (short for implementation; better naming ideas?) for each location we are
>> > watching using hardware watchpoints.  This will simplify a lot of code.  It
>> > will also eventually become easier to object-orient our breakpoints.
> 
>> 
>> How about "user breakpoints" and "machine breakpoints"?
> 
> 
> I like it.

Daniel, did you mention somewhere that the debugger book used "logical" 
and "physical" breakpoint?  If it does, it might be better to adopt its 
terminology here.

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 03:52:36PM -0400, Andrew Cagney wrote:
> >On the infrastructure side we will be able to have an "impl_breakpoint"
> >>> (short for implementation; better naming ideas?) for each location we 
> >>are
> >>> watching using hardware watchpoints.  This will simplify a lot of code. 
> >>It
> >>> will also eventually become easier to object-orient our breakpoints.
> >
> >>
> >>How about "user breakpoints" and "machine breakpoints"?
> >
> >
> >I like it.
> 
> Daniel, did you mention somewhere that the debugger book used "logical" 
> and "physical" breakpoint?  If it does, it might be better to adopt its 
> terminology here.

No, but Joel did.  I'd rather not though; the name doesn't make as much
sense to me as Jim's suggestion, and I don't think that the one book
(even if it's close to the only book...) counts as enough of a
precedent to set terminology.

Jim even kindly gave me three paragraphs of explanatory verbiage
describing what they are :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

>> Daniel, did you mention somewhere that the debugger book used "logical" 
>> and "physical" breakpoint?  If it does, it might be better to adopt its 
>> terminology here.
> 
> 
> No, but Joel did.  I'd rather not though; the name doesn't make as much
> sense to me as Jim's suggestion, and I don't think that the one book
> (even if it's close to the only book...) counts as enough of a
> precedent to set terminology.

I know of two books, the other is the GDB internals.

I find "machine" is too vague and non-commital while "physical" strongly 
suggests suggests that it is tangable or concrete.  "user" vs "logical" 
is well, whatever (although "physical" and "logical" tend to go together 
giving a familar paring).

> Jim even kindly gave me three paragraphs of explanatory verbiage
> describing what they are :)

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 05:09:08PM -0400, Andrew Cagney wrote:
> 
> >>Daniel, did you mention somewhere that the debugger book used "logical" 
> >>and "physical" breakpoint?  If it does, it might be better to adopt its 
> >>terminology here.
> >
> >
> >No, but Joel did.  I'd rather not though; the name doesn't make as much
> >sense to me as Jim's suggestion, and I don't think that the one book
> >(even if it's close to the only book...) counts as enough of a
> >precedent to set terminology.
> 
> I know of two books, the other is the GDB internals.
> 
> I find "machine" is too vague and non-commital while "physical" strongly 
> suggests suggests that it is tangable or concrete.  "user" vs "logical" 
> is well, whatever (although "physical" and "logical" tend to go together 
> giving a familar paring).

I don't find "machine" particularly vague.  On the other hand, I find
"physical" inaccurate - doubly so for software (i.e. not hardware)
breakpoints.

I'll think about it some more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Wed, Oct 08, 2003 at 05:09:08PM -0400, Andrew Cagney wrote:
 > > 
 > > >>Daniel, did you mention somewhere that the debugger book used "logical" 
 > > >>and "physical" breakpoint?  If it does, it might be better to adopt its 
 > > >>terminology here.
 > > >
 > > >
 > > >No, but Joel did.  I'd rather not though; the name doesn't make as much
 > > >sense to me as Jim's suggestion, and I don't think that the one book
 > > >(even if it's close to the only book...) counts as enough of a
 > > >precedent to set terminology.
 > > 
 > > I know of two books, the other is the GDB internals.
 > > 
 > > I find "machine" is too vague and non-commital while "physical" strongly 
 > > suggests suggests that it is tangable or concrete.  "user" vs "logical" 
 > > is well, whatever (although "physical" and "logical" tend to go together 
 > > giving a familar paring).
 > 
 > I don't find "machine" particularly vague.  On the other hand, I find
 > "physical" inaccurate - doubly so for software (i.e. not hardware)
 > breakpoints.
 > 
 > I'll think about it some more.

abstract/actual or virtual/actual?

elena

 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> I know of two books, the other is the GDB internals.
>> 
>> I find "machine" is too vague and non-commital while "physical" strongly 
>> suggests suggests that it is tangable or concrete.  "user" vs "logical" 
>> is well, whatever (although "physical" and "logical" tend to go together 
>> giving a familar paring).
> 
> 
> I don't find "machine" particularly vague.  On the other hand, I find
> "physical" inaccurate - doubly so for software (i.e. not hardware)
> breakpoints.

I'm of the same opinion for "machine", I guess we're both missing it.

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Andrew Cagney wrote:
>> On the infrastructure side we will be able to have an "impl_breakpoint"
>>
>>> > (short for implementation; better naming ideas?) for each location 
>>> we are
>>> > watching using hardware watchpoints.  This will simplify a lot of 
>>> code.  It
>>> > will also eventually become easier to object-orient our breakpoints.
>>
>>
>>>
>>> How about "user breakpoints" and "machine breakpoints"?
>>
>>
>>
>> I like it.
> 
> 
> Daniel, did you mention somewhere that the debugger book used "logical" 
> and "physical" breakpoint?  If it does, it might be better to adopt its 
> terminology here.

We should think of what would be most meaningful to the user --
not to us.  What would "machine breakpoint" mean to a user?

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 12:19:08PM -0700, Michael Snyder wrote:
> Andrew Cagney wrote:
> >>On the infrastructure side we will be able to have an "impl_breakpoint"
> >>
> >>>> (short for implementation; better naming ideas?) for each location 
> >>>we are
> >>>> watching using hardware watchpoints.  This will simplify a lot of 
> >>>code.  It
> >>>> will also eventually become easier to object-orient our breakpoints.
> >>
> >>
> >>>
> >>>How about "user breakpoints" and "machine breakpoints"?
> >>
> >>
> >>
> >>I like it.
> >
> >
> >Daniel, did you mention somewhere that the debugger book used "logical" 
> >and "physical" breakpoint?  If it does, it might be better to adopt its 
> >terminology here.
> 
> We should think of what would be most meaningful to the user --
> not to us.  What would "machine breakpoint" mean to a user?

Does anyone have any other comments on these eight submitted patches? 
So far, if I haven't lost any messages, the only disagreement is on
what to call impl_breakpoint:
  user / implementation (my implementation)
  user / machine (jim's suggestion)
  logical / physical (how debuggers work)
  virtual / actual (elena)
  abstract / actual (elena)

I think user / machine is the clearest of these.  Others disagree with
me - no clear consensus.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> 
> Does anyone have any other comments on these eight submitted patches?

Ask michael.

> So far, if I haven't lost any messages, the only disagreement is on
> what to call impl_breakpoint:
>   user / implementation (my implementation)
>   user / machine (jim's suggestion)
>   logical / physical (how debuggers work)
>   virtual / actual (elena)
>   abstract / actual (elena)
> 
> I think user / machine is the clearest of these.  Others disagree with
> me - no clear consensus.

Pretty clear objections to your suggestions though:

user/impl:
+ danielj
user/mach:
+ danielj, jimb
- cagney
- michael
- joel?
logical/physical
+ cagney
+ joel?
virtual/actual
+ elena?
abstract/actual
+ elena?

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[David Carlton]

I hesitate to add to this thread, but:

On Tue, 14 Oct 2003 11:40:13 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Pretty clear objections to your suggestions though:

> user/impl:
> + danielj
> user/mach:
> + danielj, jimb
> - cagney
> - michael
> - joel?

I liked it too.  And Joel's message says:

[ joel ]
>[ jimb ]
>> How about "user breakpoints" and "machine breakpoints"?

> "How Debuggers Work" define "logical" and "physical". But I really
> prefer Jim's proposal, especially the "user" one, as it sounds
> clearer than "logical".

I don't see how to read that as preferring logical/physical over
user/machine.

David Carlton
carlton@kealia.com

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Tue, Oct 14, 2003 at 11:40:13AM -0400, Andrew Cagney wrote:
> >
> >Does anyone have any other comments on these eight submitted patches?
> 
> Ask michael.

That's what I was doing :)

> >So far, if I haven't lost any messages, the only disagreement is on
> >what to call impl_breakpoint:
> >  user / implementation (my implementation)
> >  user / machine (jim's suggestion)
> >  logical / physical (how debuggers work)
> >  virtual / actual (elena)
> >  abstract / actual (elena)
> >
> >I think user / machine is the clearest of these.  Others disagree with
> >me - no clear consensus.
> 
> Pretty clear objections to your suggestions though:

Eh, if you're going to count beans...

> 
> user/impl:
> + danielj

Some objections but I don't recall.  I'm still OK with this one because
implementation is the clearest way I can find to say what they are. 
They're the breakpoints used to implement.

> user/mach:
> + danielj, jimb
> - cagney
> - michael
> - joel?

That's +joel and +carlton.  I'm not sure whether Michael was
objecting, but rereading his message it seems plausible - Michael?

> logical/physical
> + cagney
> + joel?

Looks like -joel to me.  And -danielj was pretty clear, I think.  I
dislike this because logical/physical breakpoints says to me that one
of them is placed at a logical (virtual) address and the other at a
physical address.

> virtual/actual
> + elena?
> abstract/actual
> + elena?

Actual doesn't have the right ring to me, and neither does abstract,
but these are moving it the right direction.  I could just use
user/lowlevel or highlevel/lowlevel, to muddy the waters further.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Tue, Oct 14, 2003 at 11:40:13AM -0400, Andrew Cagney wrote:
 > > >
 > > >Does anyone have any other comments on these eight submitted patches?
 > > 
 > > Ask michael.
 > 
 > That's what I was doing :)
 > 
 > > >So far, if I haven't lost any messages, the only disagreement is on
 > > >what to call impl_breakpoint:
 > > >  user / implementation (my implementation)
 > > >  user / machine (jim's suggestion)
 > > >  logical / physical (how debuggers work)
 > > >  virtual / actual (elena)
 > > >  abstract / actual (elena)
 > > >
 > > >I think user / machine is the clearest of these.  Others disagree with
 > > >me - no clear consensus.
 > > 
 > > Pretty clear objections to your suggestions though:
 > 
 > Eh, if you're going to count beans...
 > 
 > > 
 > > user/impl:
 > > + danielj
 > 
 > Some objections but I don't recall.  I'm still OK with this one because
 > implementation is the clearest way I can find to say what they are. 
 > They're the breakpoints used to implement.

I find it hard to connect "impl" to "implementation", my first though
is that it means "implicit". That's my objection to 'impl'.

 > 
 > > user/mach:
 > > + danielj, jimb
 > > - cagney
 > > - michael
 > > - joel?
 > 
 > That's +joel and +carlton.  I'm not sure whether Michael was
 > objecting, but rereading his message it seems plausible - Michael?
 > 
 > > logical/physical
 > > + cagney
 > > + joel?
 > 
 > Looks like -joel to me.  And -danielj was pretty clear, I think.  I
 > dislike this because logical/physical breakpoints says to me that one
 > of them is placed at a logical (virtual) address and the other at a
 > physical address.
 > 
 > > virtual/actual
 > > + elena?
 > > abstract/actual
 > > + elena?
 > 
 > Actual doesn't have the right ring to me, and neither does abstract,
 > but these are moving it the right direction.  I could just use
 > user/lowlevel or highlevel/lowlevel, to muddy the waters further.
 > 

I looked at a thesaurus, and while there seem to be tons of synonyms
for the 'high' level breakpoint concept, I found almost nothing to
convey the low level idea. "Instantiation"? I was trying to borrow terms
from the general language arena, where there are one-to-many relations
with polymorphism.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Tue, Oct 14, 2003 at 11:40:13AM -0400, Andrew Cagney wrote:
> 
>>>Does anyone have any other comments on these eight submitted patches?
>>
>>Ask michael.
> 
> 
> That's what I was doing :)

I've been following, didn't really have anything to add.

>>user/impl:
>>user/mach:
>>logical/physical
>>virtual/actual
>>abstract/actual
[...]
> That's +joel and +carlton.  I'm not sure whether Michael was
> objecting, but rereading his message it seems plausible - Michael?

Argh, I hate these questions.  ;-)  The HPDF forum used to
get bogged down endlessly in this level of detail.

I don't think any of those pairs would convey at first glance
what the distinction is, to an average user (I hesitated to
say "naive").  With your or my knowledge of debugger internals,
we might look at almost any of those and figure out what they
mean, but ask someone who doesn't know what a register is...

If this is just an internals issue, then toss a coin, it
doesn't matter.  But for the picture that we present to the
user, remember -- we always present a fictional picture that
hides most of the underlying details.  The unsophisticated
user thinks he is debugging his code -- not the underlying
machine.  If possible, he doesn't want to know eg. that
line seventeen has been broken into several locations and
intermixed with code from 3 other lines.  We're sometimes
forced to tell him anyway, but we don't if we can avoid it.

 From that perspective, I think a breakpoint is a breakpoint.
To the user it represents a location in the *source* code.
The fact that this may translate to several locations in
the machine code is "under the hood", so to speak.  If he
wants that level of information, we should give it to him,
but maybe the metaphor should reflect the fact that this is
"what's inside the box", as opposed to, like, two different
kinds of breakpoint (virtual/actual or whatever).  So for
instance, we might say that *this* is the breakpoint, and
if you want to know, *these* are the breakpoint's *locations*.

There -- you asked for my opinion.  Are you happy?   ;-)

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> If this is just an internals issue, then toss a coin, it
> doesn't matter.  But for the picture that we present to the
> user, remember -- we always present a fictional picture that
> hides most of the underlying details.  The unsophisticated
> user thinks he is debugging his code -- not the underlying
> machine.  If possible, he doesn't want to know eg. that
> line seventeen has been broken into several locations and
> intermixed with code from 3 other lines.  We're sometimes
> forced to tell him anyway, but we don't if we can avoid it.

Yes, it is user visible (which is why people are also looking for a 
user-level command, different to "maint info break" and "info break", 
that displays both the logical and physical breakpoint).

With a GUI, I can see each logical breakpoint having an expand widget 
(correct technical term is?) that lets the user see (modify?) the 
underlying physical breakpoint list.

This is needed, as otherwize something apparently simple "break strcmp" 
could result in the user unknowingly setting 1000's of breakpoints.

enjoy,
Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Andrew Cagney wrote:
> 
>> If this is just an internals issue, then toss a coin, it
>> doesn't matter.  But for the picture that we present to the
>> user, remember -- we always present a fictional picture that
>> hides most of the underlying details.  The unsophisticated
>> user thinks he is debugging his code -- not the underlying
>> machine.  If possible, he doesn't want to know eg. that
>> line seventeen has been broken into several locations and
>> intermixed with code from 3 other lines.  We're sometimes
>> forced to tell him anyway, but we don't if we can avoid it.
> 
> 
> Yes, it is user visible (which is why people are also looking for a 
> user-level command, different to "maint info break" and "info break", 
> that displays both the logical and physical breakpoint).

Yep.  Didn't mean to imply that it wasn't user visible.

> With a GUI, I can see each logical breakpoint having an expand widget 
> (correct technical term is?) that lets the user see (modify?) the 
> underlying physical breakpoint list.

Yep, pretty much what I had in mind.  For the cli interface
I would hope for something similar -- something that initially
displayed only the "high level" breakpoints, but maybe with an
asterisk or something to indicate that there was more to the
picture if one wanted to know.  And some syntax equivalent to
clicking on the GUI expand widget, which could be a variation
on an existing command, or a new command (I have no preference).


> This is needed, as otherwize something apparently simple "break strcmp" 
> could result in the user unknowingly setting 1000's of breakpoints.

That's true as it is -- I guess what we have now is that
pop-up menu that says "Which one of these did you mean?"
I presume that when that interface was implemented, we
did not expect it to come up all that often.  Now, with
overloaded functions, templates, weird constructors and
so forth, we anticipate that it will come up more often,
so we need a less intrusive interface.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> 
> 
> > This is needed, as otherwize something apparently simple "break strcmp" could result in the user unknowingly setting 1000's of breakpoints.
> 
> That's true as it is -- I guess what we have now is that
> pop-up menu that says "Which one of these did you mean?"
> I presume that when that interface was implemented, we
> did not expect it to come up all that often.  Now, with
> overloaded functions, templates, weird constructors and
> so forth, we anticipate that it will come up more often,
> so we need a less intrusive interface. 

I'd hazard a guess that the current breakpoint interface and mechanism 
pre-date GCC's inline support (which is well before GCC's C++ support)!

enjoy,
Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Andrew Cagney wrote:
>>
>>
>> > This is needed, as otherwize something apparently simple "break 
>> strcmp" could result in the user unknowingly setting 1000's of 
>> breakpoints.
>>
>> That's true as it is -- I guess what we have now is that
>> pop-up menu that says "Which one of these did you mean?"
>> I presume that when that interface was implemented, we
>> did not expect it to come up all that often.  Now, with
>> overloaded functions, templates, weird constructors and
>> so forth, we anticipate that it will come up more often,
>> so we need a less intrusive interface. 
> 
> 
> I'd hazard a guess that the current breakpoint interface and mechanism 
> pre-date GCC's inline support (which is well before GCC's C++ support)!

If you mean the dups-list with prompt, I make it 1993 at latest.
Hey, a 10-year-old interface!

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> 
> If you mean the dups-list with prompt, I make it 1993 at latest.
> Hey, a 10-year-old interface! 

I was thinking of the underlying flat linked-list.  That's been there 
since day two.

Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Andrew Cagney wrote:
>>
>> If you mean the dups-list with prompt, I make it 1993 at latest.
>> Hey, a 10-year-old interface! 
> 
> 
> I was thinking of the underlying flat linked-list.  That's been there 
> since day two.

Ja sure, you bet'cha...

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Michael Snyder writes:
 > Andrew Cagney wrote:
 > > 
 > >> If this is just an internals issue, then toss a coin, it
 > >> doesn't matter.  But for the picture that we present to the
 > >> user, remember -- we always present a fictional picture that
 > >> hides most of the underlying details.  The unsophisticated
 > >> user thinks he is debugging his code -- not the underlying
 > >> machine.  If possible, he doesn't want to know eg. that
 > >> line seventeen has been broken into several locations and
 > >> intermixed with code from 3 other lines.  We're sometimes
 > >> forced to tell him anyway, but we don't if we can avoid it.
 > > 
 > > 
 > > Yes, it is user visible (which is why people are also looking for a 
 > > user-level command, different to "maint info break" and "info break", 
 > > that displays both the logical and physical breakpoint).
 > 
 > Yep.  Didn't mean to imply that it wasn't user visible.
 > 
 > > With a GUI, I can see each logical breakpoint having an expand widget 
 > > (correct technical term is?) that lets the user see (modify?) the 
 > > underlying physical breakpoint list.
 > 
 > Yep, pretty much what I had in mind.  For the cli interface
 > I would hope for something similar -- something that initially
 > displayed only the "high level" breakpoints, but maybe with an
 > asterisk or something to indicate that there was more to the
 > picture if one wanted to know.  And some syntax equivalent to
 > clicking on the GUI expand widget, which could be a variation
 > on an existing command, or a new command (I have no preference).
 > 
 > 
 > > This is needed, as otherwize something apparently simple "break strcmp" 
 > > could result in the user unknowingly setting 1000's of breakpoints.
 > 
 > That's true as it is -- I guess what we have now is that
 > pop-up menu that says "Which one of these did you mean?"
 > I presume that when that interface was implemented, we
 > did not expect it to come up all that often.  Now, with
 > overloaded functions, templates, weird constructors and
 > so forth, we anticipate that it will come up more often,
 > so we need a less intrusive interface.
 > 
 > 
 > 


The CLI needs to provide information in at least 3 cases, that I can
think of.

1. insert the breakpoint, show confirmation to the user. If we have 20
   'real' breakpoints inserted, what do we tell the user? 

2. hit the breakpoint, show line info about where we stopped, and
   breakpoint number. Do we just say the program hit the high level
   breakpoint number, or also which low level breakpoint number? Hmm,
   do low level breakpoints have numbers? (I can see that we kind of
   need a pair of numbers now).

3. list the breakpoints (info break) Ok, this we kind of discussed.



And MI? what should we do there? the same 3 cases occur.  I would
think that MI could just tell the gui everything every time, and then
the GUI could decide to display what it wants.  However that's a lot
of information sent back and forth, maybe for no real advantage. So
maybe a two-tier command set is needed there too.  Depending on which
'view' the gui is in (I can imagine a gui having 2 views, one which
shows all the hidden bps, and one that shows only the high level
ones), or in general depending on what it wants to display it would
send different commands to gdb/MI.

elena

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@redhat.com>
> Date: Wed, 15 Oct 2003 15:07:41 -0400
> 
> 1. insert the breakpoint, show confirmation to the user. If we have 20
>    'real' breakpoints inserted, what do we tell the user? 

If we can guess the one address which is what the user wants to see in
the current context, let's show that single address.  Otherwise, let's
either show all of them or none at all, perhaps controlled by some
user option.

> 2. hit the breakpoint, show line info about where we stopped, and
>    breakpoint number. Do we just say the program hit the high level
>    breakpoint number, or also which low level breakpoint number?

I'd say we show the high-level number and the precise machine address
where it breaks.

>    Hmm, do low level breakpoints have numbers?

I don't think we need numbers for them, so let's not have them.

> And MI? what should we do there? the same 3 cases occur.  I would
> think that MI could just tell the gui everything every time, and then
> the GUI could decide to display what it wants.

Probably.

> However that's a lot
> of information sent back and forth, maybe for no real advantage. So
> maybe a two-tier command set is needed there too.

Yes, probably.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
> > From: Elena Zannoni <ezannoni@redhat.com>
> > Date: Wed, 15 Oct 2003 15:07:41 -0400
> > 
> > 1. insert the breakpoint, show confirmation to the user. If we have 20
> >    'real' breakpoints inserted, what do we tell the user? 
> 
> If we can guess the one address which is what the user wants to see in
> the current context, let's show that single address.  Otherwise, let's
> either show all of them or none at all, perhaps controlled by some
> user option.

Seems reasonable.

> > 2. hit the breakpoint, show line info about where we stopped, and
> >    breakpoint number. Do we just say the program hit the high level
> >    breakpoint number, or also which low level breakpoint number?
> 
> I'd say we show the high-level number and the precise machine address
> where it breaks.

Right now we show the breakpoint address for breakpoints which are not
at the beginning of a source line, and just the breakpoint and line
numbers for breakpoints which are at the beginning of a line.  How
would this interact with that?  Show the address always, or for
breakpoints which either are in the middle of a line or in multiple
locations?

> >    Hmm, do low level breakpoints have numbers?
> 
> I don't think we need numbers for them, so let's not have them.

I actually think that we do need numbers for them.

My hypothetical use case is something like this:
(gdb) break inline_foo
Breakpoint 5 set at inline_foo, which has multiple locations.
Say "info breakpoint 5" for more details.
(gdb) info break 5
Num Type          Enb Address    What
1   sw breakpoint  y  0x8040222  inlined into foo
2   sw breakpoint  y  0x8040822  inlined into bar
3   sw breakpoint  y  0x8040852  inlined into boring_loop
(gdb) disable 5.3
(gdb) run

I am not sure about "delete 5.3", though - that makes tracking which
breakpoints have been set a little trickier, for not much gain.

> > And MI? what should we do there? the same 3 cases occur.  I would
> > think that MI could just tell the gui everything every time, and then
> > the GUI could decide to display what it wants.
> 
> Probably.
> 
> > However that's a lot
> > of information sent back and forth, maybe for no real advantage. So
> > maybe a two-tier command set is needed there too.
> 
> Yes, probably.

These make sense to me also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii
 Daniel> wrote:
 >> ...
 >> I'd say we show the high-level number and the precise machine
 >> address where it breaks.

 Daniel> Right now we show the breakpoint address for breakpoints
 Daniel> which are not at the beginning of a source line, and just the
 Daniel> breakpoint and line numbers for breakpoints which are at the
 Daniel> beginning of a line.  How would this interact with that?
 Daniel> Show the address always, or for breakpoints which either are
 Daniel> in the middle of a line or in multiple locations?

I prefer things to be consistent, so I'd say always show the address
and also always show the source location.

    paul

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
 > > > From: Elena Zannoni <ezannoni@redhat.com>
 > > > Date: Wed, 15 Oct 2003 15:07:41 -0400
 > > > 
 > > > 1. insert the breakpoint, show confirmation to the user. If we have 20
 > > >    'real' breakpoints inserted, what do we tell the user? 
 > > 
 > > If we can guess the one address which is what the user wants to see in
 > > the current context, let's show that single address.  Otherwise, let's
 > > either show all of them or none at all, perhaps controlled by some
 > > user option.
 > 
 > Seems reasonable.
 > 

sounds ok to me.

Just occurred to me that maybe the user sometimes would want to set a
breakpoint in just one particular instance of an inlined function, we
should still allow that. I.e. should setting the multiple breakpoints
be the default?



 > > > 2. hit the breakpoint, show line info about where we stopped, and
 > > >    breakpoint number. Do we just say the program hit the high level
 > > >    breakpoint number, or also which low level breakpoint number?
 > > 
 > > I'd say we show the high-level number and the precise machine address
 > > where it breaks.
 > 
 > Right now we show the breakpoint address for breakpoints which are not
 > at the beginning of a source line, and just the breakpoint and line
 > numbers for breakpoints which are at the beginning of a line.  How
 > would this interact with that?  Show the address always, or for
 > breakpoints which either are in the middle of a line or in multiple
 > locations?
 > 

Maybe we should show 'Breakpoint 5.3' and then use the same rule we
have now to decide whether to show the line or the address. This way
the user knows which high level bp was hit.  How a gui is going to
represent that, it's beyond me. 

 > > >    Hmm, do low level breakpoints have numbers?
 > > 
 > > I don't think we need numbers for them, so let's not have them.
 > 
 > I actually think that we do need numbers for them.
 > 
 > My hypothetical use case is something like this:
 > (gdb) break inline_foo
 > Breakpoint 5 set at inline_foo, which has multiple locations.
 > Say "info breakpoint 5" for more details.
 > (gdb) info break 5
 > Num Type          Enb Address    What
 > 1   sw breakpoint  y  0x8040222  inlined into foo
 > 2   sw breakpoint  y  0x8040822  inlined into bar
 > 3   sw breakpoint  y  0x8040852  inlined into boring_loop
 > (gdb) disable 5.3
 > (gdb) run
 > 

Yes, I was thinking something like that too. Even though, there should
probably be a 5 somewhere in the output of info break.

 > I am not sure about "delete 5.3", though - that makes tracking which
 > breakpoints have been set a little trickier, for not much gain.
 > 

Maybe delete could be implemented internally as mark the child
breakpoint as deleted, instead of removing it from the list. Similar
to disabling it but the user will not be able to access it ever again.

 > > > And MI? what should we do there? the same 3 cases occur.  I would
 > > > think that MI could just tell the gui everything every time, and then
 > > > the GUI could decide to display what it wants.
 > > 
 > > Probably.
 > > 
 > > > However that's a lot
 > > > of information sent back and forth, maybe for no real advantage. So
 > > > maybe a two-tier command set is needed there too.
 > > 
 > > Yes, probably.
 > 
 > These make sense to me also.
 > 

I'd like to hear from MI users otherwise we'll be designing in a vacuum.
I'll send something to the eclipse folks.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@redhat.com>
> Date: Thu, 16 Oct 2003 10:32:57 -0400
> 
> Just occurred to me that maybe the user sometimes would want to set a
> breakpoint in just one particular instance of an inlined function, we
> should still allow that.

How about the following?

(gdb) break inline_foo
Breakpoint 5 set at inline_foo, which has multiple locations.
Say "info breakpoint 5" for more details.
(gdb) info break 5
Num Type          Enb Address    What
5   sw breakpoint  y  0x8040222  inlined into foo
5   sw breakpoint  y  0x8040822  inlined into bar
5   sw breakpoint  y  0x8040852  inlined into boring_loop
(gdb) delete 5 *0x8040852

> I.e. should setting the multiple breakpoints
> be the default?

I think this is the best default, yes.

Alternatively, we could show all possible addresses where the
requested breakpoint coulod be set and ask the user to select which
ones she wants, like this:

(gdb) break inline_foo
Function inline_foo is inlined into multiple locations:
  Address    Location
  0x8040222  inlined into foo
  0x8040822  inlined into bar
  0x8040852  inlined into boring_loop
Please use "break *address" to set breakpoints at one or more of these
(gdb) break *0x8040822 *0x8040822

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Eli Zaretskii wrote:
>>From: Elena Zannoni <ezannoni@redhat.com>

>>I.e. should setting the multiple breakpoints
>>be the default?
> 
> 
> I think this is the best default, yes.
> 
> Alternatively, we could show all possible addresses where the
> requested breakpoint coulod be set and ask the user to select which
> ones she wants, 

That's the current behavior.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
>  > > > From: Elena Zannoni <ezannoni@redhat.com>
>  > > > Date: Wed, 15 Oct 2003 15:07:41 -0400
>  > > > 
>  > > > 1. insert the breakpoint, show confirmation to the user. If we have 20
>  > > >    'real' breakpoints inserted, what do we tell the user? 
>  > > 
>  > > If we can guess the one address which is what the user wants to see in
>  > > the current context, let's show that single address.  Otherwise, let's
>  > > either show all of them or none at all, perhaps controlled by some
>  > > user option.
>  > 
>  > Seems reasonable.
>  > 
> 
> sounds ok to me.
> 
> Just occurred to me that maybe the user sometimes would want to set a
> breakpoint in just one particular instance of an inlined function, we
> should still allow that. I.e. should setting the multiple breakpoints
> be the default?

Going by what we have now, consider homonymic static functions.
If you say "break foo", it's ambiguous, and gdb currently
asks you which one you mean (with the option to say "all of them").

But if you want to specify one, you can say "break aout.c::foo".

Similarly with overloaded functions and templates.  You spell out
the function signature.

As always, I am unsure how to handle compiler-generated stuff
that may not have a source location.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 09:11:44 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> Show the address always, or for breakpoints which either are in the
> middle of a line or in multiple locations?

I don't see any problem with this logic.  Do you?

> I actually think that we do need numbers for them.
> 
> My hypothetical use case is something like this:
> (gdb) break inline_foo
> Breakpoint 5 set at inline_foo, which has multiple locations.
> Say "info breakpoint 5" for more details.
> (gdb) info break 5
> Num Type          Enb Address    What
> 1   sw breakpoint  y  0x8040222  inlined into foo
> 2   sw breakpoint  y  0x8040822  inlined into bar
> 3   sw breakpoint  y  0x8040852  inlined into boring_loop
> (gdb) disable 5.3

It's possible to use 5.3, although I'd then expect that number to
appear in "info break 5", like this:

(gdb) info break 5
Num   Type          Enb Address    What
5.1   sw breakpoint  y  0x8040222  inlined into foo
5.2   sw breakpoint  y  0x8040822  inlined into bar
5.3   sw breakpoint  y  0x8040852  inlined into boring_loop

However, I'm also uneasy about "delete 5.3", and in addition I'm
afraid that having two sets of breakpoint numbers will mess up things
in the long run.  So how about the following?

(gdb) info break 5
Num Type          Enb Address    What
5   sw breakpoint  y  0x8040222  inlined into foo
5   sw breakpoint  y  0x8040822  inlined into bar
5   sw breakpoint  y  0x8040852  inlined into boring_loop
(gdb) disable 5 *0x8040852

In other words, let's allow the user to specify an optional location
in addition to the breakpoint number.

We could even use "disable *0x8040852".

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
> 
>>>From: Elena Zannoni <ezannoni@redhat.com>

>>>2. hit the breakpoint, show line info about where we stopped, and
>>>   breakpoint number. Do we just say the program hit the high level
>>>   breakpoint number, or also which low level breakpoint number?
>>
>>I'd say we show the high-level number and the precise machine address
>>where it breaks.
> 
> Right now we show the breakpoint address for breakpoints which are not
> at the beginning of a source line, and just the breakpoint and line
> numbers for breakpoints which are at the beginning of a line.  How
> would this interact with that?  Show the address always, or for
> breakpoints which either are in the middle of a line or in multiple
> locations?

I think right now we show the address only when it doesn't have
a clear one-to-one relationship with a source location.  For instance
if it falls in the middle of a line, or a function prologue (same
thing, actually, it's just a special case of a line).

In the one-to-many case, I'd say that if the breakpoint has a
fan-out of one (ie. only one location), AND it corresponds to
a specific source line, then we just report the line.  For
mid-lines, we do the same as before (show the address).
If it's a breakpoint with multiple locations, then we need
to qualify it -- distinguish somehow which one was hit.

The way to qualify it might depend on the kind of fan-out.
In many cases, the source file might be enough.  Or maybe
the function signiture.

I'm still in the fog about the machine-generated constructors...



>>>   Hmm, do low level breakpoints have numbers?
>>
>>I don't think we need numbers for them, so let's not have them.
> 
> I actually think that we do need numbers for them.

I suspect so too.

> 
> My hypothetical use case is something like this:
> (gdb) break inline_foo
> Breakpoint 5 set at inline_foo, which has multiple locations.
> Say "info breakpoint 5" for more details.
> (gdb) info break 5
> Num Type          Enb Address    What
> 1   sw breakpoint  y  0x8040222  inlined into foo
> 2   sw breakpoint  y  0x8040822  inlined into bar
> 3   sw breakpoint  y  0x8040852  inlined into boring_loop
> (gdb) disable 5.3
> (gdb) run
> 
> I am not sure about "delete 5.3", though - that makes tracking which
> breakpoints have been set a little trickier, for not much gain.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Tue, Oct 14, 2003 at 01:45:18PM -0700, Michael Snyder wrote:
> I don't think any of those pairs would convey at first glance
> what the distinction is, to an average user (I hesitated to
> say "naive").  With your or my knowledge of debugger internals,
> we might look at almost any of those and figure out what they
> mean, but ask someone who doesn't know what a register is...
> 
> If this is just an internals issue, then toss a coin, it
> doesn't matter.  But for the picture that we present to the
> user, remember -- we always present a fictional picture that
> hides most of the underlying details.  The unsophisticated
> user thinks he is debugging his code -- not the underlying
> machine.  If possible, he doesn't want to know eg. that
> line seventeen has been broken into several locations and
> intermixed with code from 3 other lines.  We're sometimes
> forced to tell him anyway, but we don't if we can avoid it.
> 
> From that perspective, I think a breakpoint is a breakpoint.
> To the user it represents a location in the *source* code.
> The fact that this may translate to several locations in
> the machine code is "under the hood", so to speak.  If he
> wants that level of information, we should give it to him,
> but maybe the metaphor should reflect the fact that this is
> "what's inside the box", as opposed to, like, two different
> kinds of breakpoint (virtual/actual or whatever).  So for
> instance, we might say that *this* is the breakpoint, and
> if you want to know, *these* are the breakpoint's *locations*.
> 
> There -- you asked for my opinion.  Are you happy?   ;-)

Quite happy :)  This suggests struct breakpoint and struct bp_location
(or maybe even bp_element, which is clearer for watchpoints, but less
clear overall).  For this approach, I see:

 Pro: it's much clearer.
 Con: it gives breakpoint two meanings in the internals documentation;
      the target sets a breakpoint according to a bp_location; a struct
      breakpoint can cause the target to set many breakpoints.  But I
      think that if we have to be confused somewhere, that's the place
      to put the confusion.

Do others like this?  I have a couple of other flagged messages to
respond to in this thread, but they all seem to have moved onto the
general multi-breakpoints problem.

Michael, once we're agreed on a name could you review the cleanup
patches?  Then I'll put together a branch for the interesting bits.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Wed, 15 Oct 2003 18:41:34 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > From that perspective, I think a breakpoint is a breakpoint.
> > To the user it represents a location in the *source* code.
> > The fact that this may translate to several locations in
> > the machine code is "under the hood", so to speak.  If he
> > wants that level of information, we should give it to him,
> > but maybe the metaphor should reflect the fact that this is
> > "what's inside the box", as opposed to, like, two different
> > kinds of breakpoint (virtual/actual or whatever).  So for
> > instance, we might say that *this* is the breakpoint, and
> > if you want to know, *these* are the breakpoint's *locations*.
> > 
> > There -- you asked for my opinion.  Are you happy?   ;-)
> 
> Quite happy :)  This suggests struct breakpoint and struct bp_location

I'm with Michael here.  You might recall that I originally suggested
to call those impl_breakpoint's just ``locations'' or ``addresses''
of a particular breakpoint.

If ``location'' is not good enough (after all, there's other
information stored about each address, like the kind of trap we set
there), let's use some more vague word, like bp_spot or maybe
bp_instance.

>  Con: it gives breakpoint two meanings in the internals documentation;
>       the target sets a breakpoint according to a bp_location; a struct
>       breakpoint can cause the target to set many breakpoints.

That's just a choice of words that confuses you.  I suggest a
different choice of words: the target sets a breakpoint according
information in bp_location; a struct breakpoint can cause a target to
set the breakpoint in several locations (or at several addresses).

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> Quite happy :)  This suggests struct breakpoint and struct bp_location
> 
> 
> I'm with Michael here.  You might recall that I originally suggested
> to call those impl_breakpoint's just ``locations'' or ``addresses''
> of a particular breakpoint.
> 
> If ``location'' is not good enough (after all, there's other
> information stored about each address, like the kind of trap we set
> there), let's use some more vague word, like bp_spot or maybe
> bp_instance.

BTW, long term, this stuff is going to be hijacked by other *point 
mechanisms.  Variable watchpoints, for instance, will be given a similar 
projection (the watchpoint changes that last year stalled can probably 
be picked up again).  While the term "breakpoint" may continue to be 
used, it will be applied to more than just breakpoints.

(Happened to talk to fernado about his uni GDB work and he explained 
that that the logical/physical separation occures all over the place - 
happened to also use log/phys without my prompting :-).

Andrew

PS: To make everyone feel ill - logical_debugpoint, physical_debugpoint ...

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 10:25:26 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> BTW, long term, this stuff is going to be hijacked by other *point 
> mechanisms.  Variable watchpoints, for instance, will be given a similar 
> projection (the watchpoint changes that last year stalled can probably 
> be picked up again).  While the term "breakpoint" may continue to be 
> used, it will be applied to more than just breakpoints.

I don't see any problems with that.  In fact, we might wish to start
educating GDB users to use the term ``breakpoint'' for all of those.
E.g., many implementations of dbx and other debuggers support
watchpoints, but call them ``breakpoints'' or ``data breakpoints''.
Someone whose first debugger was GDB might not even find how to set
watchpoints unless they try looking for "breakpoint".

In other words, we actually set a trap in each of these *point
situations, so they are really very much alike.  Therefore, it comes
as no surprise that they share many similar features and are all
described by struct breakpoint.

> (Happened to talk to fernado about his uni GDB work and he explained 
> that that the logical/physical separation occures all over the place - 
> happened to also use log/phys without my prompting :-).

I actually think that we should leave the term ``breakpoint'' alone,
and refer to what you call ``a physical breakpoint'' as the
breakpoint's location or instantiation.  That's because most of the
information associated with a breakpoint is stored with the ``logical
breakpoint'', whereas the ``physical breakpoint'' only stores an
address and a bunch of flags.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Thu, 16 Oct 2003 10:25:26 -0400
>>From: Andrew Cagney <cagney@gnu.org>
>>
>>BTW, long term, this stuff is going to be hijacked by other *point 
>>mechanisms.  Variable watchpoints, for instance, will be given a similar 
>>projection (the watchpoint changes that last year stalled can probably 
>>be picked up again).  While the term "breakpoint" may continue to be 
>>used, it will be applied to more than just breakpoints.
> 
> 
> I don't see any problems with that.  In fact, we might wish to start
> educating GDB users to use the term ``breakpoint'' for all of those.
> E.g., many implementations of dbx and other debuggers support
> watchpoints, but call them ``breakpoints'' or ``data breakpoints''.
> Someone whose first debugger was GDB might not even find how to set
> watchpoints unless they try looking for "breakpoint".

The difference between breakpoints and watchpoints may be small,
but the difference between breakpoints and tracepoints is large.
Some people have used the term "stop point".

Other potential stop-points are signals (synch and asynch),
throw and catch, syscalls, longjmp, synchronization, thread
switch, blocking...

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Thu, 16 Oct 2003 16:24:18 -0700
> From: Michael Snyder <msnyder@redhat.com>
> 
> The difference between breakpoints and watchpoints may be small,
> but the difference between breakpoints and tracepoints is large.

Can you elaborate?  From the user's point of view, it seems like a
tracepoint is just a fancy variation of a breakpoint, one that
performs a set of operations and then continues the inferior.

> Other potential stop-points are signals (synch and asynch),
> throw and catch, syscalls, longjmp, synchronization, thread
> switch, blocking...

These are all traps we set at code and/or data to stop the executable,
right?  So where's the big difference?

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Thu, 16 Oct 2003 16:24:18 -0700
>>From: Michael Snyder <msnyder@redhat.com>
>>
>>The difference between breakpoints and watchpoints may be small,
>>but the difference between breakpoints and tracepoints is large.
> 
> 
> Can you elaborate?  From the user's point of view, it seems like a
> tracepoint is just a fancy variation of a breakpoint, one that
> performs a set of operations and then continues the inferior.

Debugging using tracepoints is a totally different process
than debugging with breakpoints.  It's like planning and
setting up a photo or video shoot, going away while someone
else does the filming, then coming back and looking at
the results.


>>Other potential stop-points are signals (synch and asynch),
>>throw and catch, syscalls, longjmp, synchronization, thread
>>switch, blocking...
> 
> 
> These are all traps we set at code and/or data to stop the executable,
> right?  So where's the big difference?

Asynchronous signals aren't like traps at all.  They're not
associated with a source location _or_ a target location.
Of course once they happen, there will be a location where
they happened -- but the next time it will be somewhere else.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Fri, 17 Oct 2003 14:38:52 -0700
> From: Michael Snyder <msnyder@redhat.com>
> 
> Debugging using tracepoints is a totally different process
> than debugging with breakpoints.  It's like planning and
> setting up a photo or video shoot, going away while someone
> else does the filming, then coming back and looking at
> the results.

Debugging with tracepoints indeed uses a different paradigm, but
_operations_ on tracepoints are almost identical to those for
breakpoints: they have the same syntax and a very similar semantics.
Like breakpoints, each tracepoint is a trap in some point of code,
designed to do something when the program gets to that point.

> Asynchronous signals aren't like traps at all.

I didn't mean to say they were.  I meant to say that catching forks,
signals, longjmps, and syscalls works by setting traps in some
specific portions of the program's code.  So it's the same as setting
a breakpoint, we just give the user a convenience feature to ease the
way of specifying the place where to set the trap.

In other words, all these features use breakpoints of some kind, it's
only their use in the higher-level view of the debugging process is
different.  When discussing the syntax and semantics of these
commands, I think the lower-level similarity is what matters, not the
higher-level distinction of their application.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Fri, 17 Oct 2003 14:38:52 -0700
>>From: Michael Snyder <msnyder@redhat.com>
>>
>>Debugging using tracepoints is a totally different process
>>than debugging with breakpoints.  It's like planning and
>>setting up a photo or video shoot, going away while someone
>>else does the filming, then coming back and looking at
>>the results.
> 
> 
> Debugging with tracepoints indeed uses a different paradigm, but
> _operations_ on tracepoints are almost identical to those for
> breakpoints: they have the same syntax and a very similar semantics.

That's true -- by design.

> Like breakpoints, each tracepoint is a trap in some point of code,
> designed to do something when the program gets to that point.

_May_ be a trap.  That part of the implementation is on the target,
and gdb doesn't know how it is implemented.

We're both right -- the interface is very similar, but the
concept and the way it is used is very different.

> 
> 
>>Asynchronous signals aren't like traps at all.
> 
> 
> I didn't mean to say they were.  I meant to say that catching forks,
> signals, longjmps, and syscalls works by setting traps in some
> specific portions of the program's code. 

Except for asynchronous signals.  I haven't tried real hard
to find other exceptions, but that's one.


> So it's the same as setting
> a breakpoint, we just give the user a convenience feature to ease the
> way of specifying the place where to set the trap.
> 
> In other words, all these features use breakpoints of some kind, it's
> only their use in the higher-level view of the debugging process is
> different.  When discussing the syntax and semantics of these
> commands, I think the lower-level similarity is what matters, not the
> higher-level distinction of their application.

Well, again, the interface may be the same.  The implementation
may be similar (although in many cases we're actually setting a
"mystery breakpoint" at a location the user knows nothging about).
But conceptually they are very different.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 16, 2003 at 10:25:26AM -0400, Andrew Cagney wrote:
> >Quite happy :)  This suggests struct breakpoint and struct bp_location
> >
> >
> >I'm with Michael here.  You might recall that I originally suggested
> >to call those impl_breakpoint's just ``locations'' or ``addresses''
> >of a particular breakpoint.
> >
> >If ``location'' is not good enough (after all, there's other
> >information stored about each address, like the kind of trap we set
> >there), let's use some more vague word, like bp_spot or maybe
> >bp_instance.
> 
> BTW, long term, this stuff is going to be hijacked by other *point 
> mechanisms.  Variable watchpoints, for instance, will be given a similar 
> projection (the watchpoint changes that last year stalled can probably 
> be picked up again).  While the term "breakpoint" may continue to be 
> used, it will be applied to more than just breakpoints.

Shorter term than you may think :)  My plan now is something like this:
  - Cleanup patches, as posted
  - Internal support for multiple locations per breakpoint
  - Adapt watchpoints to use the multiple locations support, which will
    be rather cleaner than what we have now.
  - Then move on to fun stuff with breakpoints.

Could you give me a pointer to the watchpoint changes you're talking
about?  I don't recall them.

> PS: To make everyone feel ill - logical_debugpoint, physical_debugpoint ...

That's the concept, but I don't think we have a real problem with
continuing to overload breakpoint for that.  Consider "info break".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> Shorter term than you may think :)  My plan now is something like this:
>   - Cleanup patches, as posted
>   - Internal support for multiple locations per breakpoint
>   - Adapt watchpoints to use the multiple locations support, which will
>     be rather cleaner than what we have now.
>   - Then move on to fun stuff with breakpoints.
> 
> Could you give me a pointer to the watchpoint changes you're talking
> about?  I don't recall them.

Start with: [rfc;rfa:breakpoint] Pass full breakpoint/watchpoint count 
to target
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=967

which should give you enough to find the discussion.  My "memory" of the 
thread is that stalled when it became apparent that a two level 
watchpoint mechanism that created a canonical(1) list of physical watch 
regions was going to be needed.

Andrew

(1) Canonical, now there's an interesting word.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[David Carlton]

On Wed, 15 Oct 2003 18:41:34 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Oct 14, 2003 at 01:45:18PM -0700, Michael Snyder wrote:

>> From that perspective, I think a breakpoint is a breakpoint.  To
>> the user it represents a location in the *source* code.  The fact
>> that this may translate to several locations in the machine code is
>> "under the hood", so to speak.
...
>> So for instance, we might say that *this* is the breakpoint, and if
>> you want to know, *these* are the breakpoint's *locations*.

> Quite happy :)  This suggests struct breakpoint and struct bp_location
> (or maybe even bp_element, which is clearer for watchpoints, but less
> clear overall).

But they're both locations - one kind of location is in the source
code, and one is in the machine code.  So I would like to have the
word 'source' in the user breakpoint structure.

David Carlton
carlton@kealia.com

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 16, 2003 at 09:03:27AM -0700, David Carlton wrote:
> On Wed, 15 Oct 2003 18:41:34 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> > On Tue, Oct 14, 2003 at 01:45:18PM -0700, Michael Snyder wrote:
> 
> >> From that perspective, I think a breakpoint is a breakpoint.  To
> >> the user it represents a location in the *source* code.  The fact
> >> that this may translate to several locations in the machine code is
> >> "under the hood", so to speak.
> ...
> >> So for instance, we might say that *this* is the breakpoint, and if
> >> you want to know, *these* are the breakpoint's *locations*.
> 
> > Quite happy :)  This suggests struct breakpoint and struct bp_location
> > (or maybe even bp_element, which is clearer for watchpoints, but less
> > clear overall).
> 
> But they're both locations - one kind of location is in the source
> code, and one is in the machine code.  So I would like to have the
> word 'source' in the user breakpoint structure.

But a user breakpoint doesn't have to be a source location - or even
have one.

(gdb) break *0x50003000

(gdb) break function_with_no_debug_info

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Elena Zannoni]

Daniel Jacobowitz writes:
 > > I think 'info break' should list the addresses.  I don't know how this
 > > should fit into the MI format, but it ought to be MI that changes,
 > > rather than omitting useful behavior.
 > > 
 > > In my ideal world, you'd get an explanation for why each address was
 > > chosen, when it's not obvious:
 > > 
 > > (gdb) info break
 > > Num Type           Disp Enb Address    What
 > > 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
 > >                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
 > > (gdb) 
 > 
 > Here's the problem that I see.
 > 
 > For foo::foo, there are two of these things.  Having them both in the
 > list would be nice.  Really nice.
 > 
 > For inline_accessor_fn there are 3.8 million.  In addition to needing
 > to do a whole lot of work on GDB internals before we could survive this
 > (memory usage; ptrace thrashing inserting and removing them; linked
 > lists of breakpoints; and that's just the beginning) this has some
 > severe user interface implications.  We don't want to print out all
 > those addresses by default!
 > 
 > I'm open to suggestions on how to deal with this.
 > 

There is already 'maint info break', how about extending that?  Would
you be able to distinguish between foo::foo breakpoints and inline
breakpoints so that they can be displayed on separate lists/commands?

elena



 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 05:06:35PM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > > I think 'info break' should list the addresses.  I don't know how this
>  > > should fit into the MI format, but it ought to be MI that changes,
>  > > rather than omitting useful behavior.
>  > > 
>  > > In my ideal world, you'd get an explanation for why each address was
>  > > chosen, when it's not obvious:
>  > > 
>  > > (gdb) info break
>  > > Num Type           Disp Enb Address    What
>  > > 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
>  > >                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
>  > > (gdb) 
>  > 
>  > Here's the problem that I see.
>  > 
>  > For foo::foo, there are two of these things.  Having them both in the
>  > list would be nice.  Really nice.
>  > 
>  > For inline_accessor_fn there are 3.8 million.  In addition to needing
>  > to do a whole lot of work on GDB internals before we could survive this
>  > (memory usage; ptrace thrashing inserting and removing them; linked
>  > lists of breakpoints; and that's just the beginning) this has some
>  > severe user interface implications.  We don't want to print out all
>  > those addresses by default!
>  > 
>  > I'm open to suggestions on how to deal with this.
>  > 
> 
> There is already 'maint info break', how about extending that?  Would
> you be able to distinguish between foo::foo breakpoints and inline
> breakpoints so that they can be displayed on separate lists/commands?

Hmm... sure, I suppose so.  I haven't thought about how well it scales
and I don't think I can until I have some implementation in front of me
to play with.  Something like this?

1   breakpoint     keep y   0x08048354 in foo::foo() (in-charge) at hello.c:8
                            0x08048364 in foo::foo() (not-in-charge) at hello.c:8

2   breakpoint     keep y   <multiple> in foo::baz at hello.c:12

3   breakpoint     keep y   <multiple> in foo::foo(int) (in-charge) at hello.c:10
                            <multiple> in foo::foo(int) (not-in-charge) at hello.c:10

Where the latter two describe inlined copies.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Wed, 8 Oct 2003 15:05:02 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > (gdb) info break
> > Num Type           Disp Enb Address    What
> > 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
> >                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
> > (gdb) 
> 
> Here's the problem that I see.
> 
> For foo::foo, there are two of these things.  Having them both in the
> list would be nice.  Really nice.
> 
> For inline_accessor_fn there are 3.8 million.  In addition to needing
> to do a whole lot of work on GDB internals before we could survive this
> (memory usage; ptrace thrashing inserting and removing them; linked
> lists of breakpoints; and that's just the beginning) this has some
> severe user interface implications.  We don't want to print out all
> those addresses by default!
> 
> I'm open to suggestions on how to deal with this.

How about a switch to "info break"?  By default, show only the
in-charge breakpoint, but if the user says "info break -all" or some
such, show the other 3.8 million minus one.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 08:10:46AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 8 Oct 2003 15:05:02 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > > 
> > > (gdb) info break
> > > Num Type           Disp Enb Address    What
> > > 1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
> > >                             0x08048364 in foo::foo (not-in-charge) at hello.c:8
> > > (gdb) 
> > 
> > Here's the problem that I see.
> > 
> > For foo::foo, there are two of these things.  Having them both in the
> > list would be nice.  Really nice.
> > 
> > For inline_accessor_fn there are 3.8 million.  In addition to needing
> > to do a whole lot of work on GDB internals before we could survive this
> > (memory usage; ptrace thrashing inserting and removing them; linked
> > lists of breakpoints; and that's just the beginning) this has some
> > severe user interface implications.  We don't want to print out all
> > those addresses by default!
> > 
> > I'm open to suggestions on how to deal with this.
> 
> How about a switch to "info break"?  By default, show only the
> in-charge breakpoint, but if the user says "info break -all" or some
> such, show the other 3.8 million minus one.

From a user interface perspective, I got a really strong negative
pushback the last time I tried to add a switch to any GDB command.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Thu, 9 Oct 2003 10:08:48 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> From a user interface perspective, I got a really strong negative
> pushback the last time I tried to add a switch to any GDB command.

Any pointers to messages where such pushback could be seen?  I'm
curious what could be the motivation.

Another possibility would be to have 2 commands: "info breakpoints"
which only shows one breakpoint for each user breakpoint, and "info
all-breakpoints", which shows all of them.  We already have a
precedent for such an arrangement with "info registers" vs "info
all-registers".

Anyway, going to the maint-land is something I think we should avoid
in this case, as the breakpoints not shown by default are interesting
not only for GDB maintainers.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 07:03:41PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 9 Oct 2003 10:08:48 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > From a user interface perspective, I got a really strong negative
> > pushback the last time I tried to add a switch to any GDB command.
> 
> Any pointers to messages where such pushback could be seen?  I'm
> curious what could be the motivation.

http://sources.redhat.com/ml/gdb-patches/2002-07/msg00499.html
http://sources.redhat.com/ml/gdb-patches/2002-07/msg00612.html
and others.

I still agree with:
http://sources.redhat.com/ml/gdb-patches/2002-07/msg00608.html

but I lost that argument.

> Another possibility would be to have 2 commands: "info breakpoints"
> which only shows one breakpoint for each user breakpoint, and "info
> all-breakpoints", which shows all of them.  We already have a
> precedent for such an arrangement with "info registers" vs "info
> all-registers".
> 
> Anyway, going to the maint-land is something I think we should avoid
> in this case, as the breakpoints not shown by default are interesting
> not only for GDB maintainers.

Michael Snyder also likes this, so all-breakpoints it is (will be). 
This will include multi-address breakpoints but not GDB internal ones
like maint info breakpoints.

What to do for MI I have no idea.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> Date: Thu, 9 Oct 2003 10:08:48 -0400
>> From: Daniel Jacobowitz <drow@mvista.com>
>> 
>> From a user interface perspective, I got a really strong negative
>> pushback the last time I tried to add a switch to any GDB command.
> 
> 
> Any pointers to messages where such pushback could be seen?  I'm
> curious what could be the motivation.

A syntax, using GDB's `/' qualifier vis:

	(gdb) info breakpoints/locations

works well.  In fact I can see a strong preference for the terse version:

	(gdb) info break/l

and that is even 1:2 characters shorter than:

	(gdb) info break --l
	(gdb) info break -l

Given that files are not involved (load/vma /lma), it also avoids 
immediatly CLI changes.

Andrew


> Another possibility would be to have 2 commands: "info breakpoints"
> which only shows one breakpoint for each user breakpoint, and "info
> all-breakpoints", which shows all of them.  We already have a
> precedent for such an arrangement with "info registers" vs "info
> all-registers".
> 
> Anyway, going to the maint-land is something I think we should avoid
> in this case, as the breakpoints not shown by default are interesting
> not only for GDB maintainers.
> 
> 

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Thu, Oct 09, 2003 at 08:10:46AM +0200, Eli Zaretskii wrote:
> 
>>>Date: Wed, 8 Oct 2003 15:05:02 -0400
>>>From: Daniel Jacobowitz <drow@mvista.com>
>>>
>>>>(gdb) info break
>>>>Num Type           Disp Enb Address    What
>>>>1   breakpoint     keep y   0x08048354 in foo::foo (in-charge) at hello.c:8
>>>>                            0x08048364 in foo::foo (not-in-charge) at hello.c:8
>>>>(gdb) 
>>>
>>>Here's the problem that I see.
>>>
>>>For foo::foo, there are two of these things.  Having them both in the
>>>list would be nice.  Really nice.
>>>
>>>For inline_accessor_fn there are 3.8 million.  In addition to needing
>>>to do a whole lot of work on GDB internals before we could survive this
>>>(memory usage; ptrace thrashing inserting and removing them; linked
>>>lists of breakpoints; and that's just the beginning) this has some
>>>severe user interface implications.  We don't want to print out all
>>>those addresses by default!
>>>
>>>I'm open to suggestions on how to deal with this.
>>
>>How about a switch to "info break"?  By default, show only the
>>in-charge breakpoint, but if the user says "info break -all" or some
>>such, show the other 3.8 million minus one.
> 
> 
>>From a user interface perspective, I got a really strong negative
> pushback the last time I tried to add a switch to any GDB command.
> 

OK, how about modeling after "info reg" vs. "info all-reg"?
Giving us "info break" and a new "info all-break".

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[David Carlton]

On 08 Oct 2003 13:05:34 -0500, Jim Blandy <jimb@redhat.com> said:

> This sounds really great.

Amen.

> When you think about what actually is happening in the debuggee, the
> mapping is actually many-to-many, since you can have multiple user
> breakpoints at the same address.  Not that this affects your data
> structures --- just an observation.

I do wonder what will happen to the duplicate breakpoint message
eventually.  Or situations where two different user breakpoints both
contain command lists and both map to the same machine breakpoint.
(Is that possible?  Probably in the case of inlining.)  But we
certainly don't have to worry about those sorts of issues right now.

> How about "user breakpoints" and "machine breakpoints"?

I like those names too. 

David Carlton
carlton@kealia.com

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 12:38:51PM -0700, David Carlton wrote:
> On 08 Oct 2003 13:05:34 -0500, Jim Blandy <jimb@redhat.com> said:
> 
> > This sounds really great.
> 
> Amen.
> 
> > When you think about what actually is happening in the debuggee, the
> > mapping is actually many-to-many, since you can have multiple user
> > breakpoints at the same address.  Not that this affects your data
> > structures --- just an observation.
> 
> I do wonder what will happen to the duplicate breakpoint message
> eventually.  Or situations where two different user breakpoints both
> contain command lists and both map to the same machine breakpoint.
> (Is that possible?  Probably in the case of inlining.)  But we
> certainly don't have to worry about those sorts of issues right now.

The duplicate breakpoint message, I don't know, but it shouldn't be too
hard.  For command lists, well, that can already happen - try it, set
them both on the same address.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Wed, 08 Oct 2003 12:38:51 -0700
> 
> [...] situations where two different user breakpoints both contain
> command lists and both map to the same machine breakpoint.  (Is that
> possible?

Yes, it's possible, and even useful: imagine several breakpoints on
the same spot, but with different conditions.

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Wed, 8 Oct 2003 12:55:34 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> On the infrastructure side we will be able to have an "impl_breakpoint"
> (short for implementation; better naming ideas?)

It looks to me that your impl_breakpoint is simply a linked list of
addresses we watch and a few flags.  So perhaps we shouldn't introduce
two kinds of breakpoints, but instead call that list something
entirely different, like bp_data (for ``breakpoint data'').

> Thoughts?  Comments on the overall approach?  OK?

I think the direction is correct.  Thanks for raising the issue and
for working on it.

Putting on my documentation maintainer's hat, may I suggest that this
project also tries to improve the documentation of our breakpoint
handling in gdbint.texinfo, at least to some degree?  IMHO it's a
shame that breakpoints, _the_ most central facility of any debugger,
are documented so poorly.

TIA

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 07:56:13PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 8 Oct 2003 12:55:34 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > On the infrastructure side we will be able to have an "impl_breakpoint"
> > (short for implementation; better naming ideas?)
> 
> It looks to me that your impl_breakpoint is simply a linked list of
> addresses we watch and a few flags.  So perhaps we shouldn't introduce
> two kinds of breakpoints, but instead call that list something
> entirely different, like bp_data (for ``breakpoint data'').

Each of them is a breakpoint, though.  Well, that or a watchpoint or a
catchpoint of some type.  The user's request has triggered the creation
of N actual breaking-points.

I'm not sure.

> > Thoughts?  Comments on the overall approach?  OK?
> 
> I think the direction is correct.  Thanks for raising the issue and
> for working on it.
> 
> Putting on my documentation maintainer's hat, may I suggest that this
> project also tries to improve the documentation of our breakpoint
> handling in gdbint.texinfo, at least to some degree?  IMHO it's a
> shame that breakpoints, _the_ most central facility of any debugger,
> are documented so poorly.

Let me take a look over what's there.  No promises :)  but when a bit
more has been done, I'll try to find time to revise it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Andrew Cagney]

> This will make it simpler to have, for instance, a breakpoint on both the
> in-charge and not-in-charge constructors without bothering the user with
> that detail.  Similarly (eventually!) for copies of an inlined function, or
> multiple copies of an executed line.  This is a bit of a ways in the future
> but I'm working on it.

I get the feeling that the naming discussion has converged to:

	"breakpoint" and "location"

where a breakpoint has 1:N locations, and multiple breakpoints can share 
common locations.

Unlike the "user" vs "machine" I don't see us having much difficulty 
explaining "breakpoint" and "location" to either users or developers.  Ya!

enjoy,
Andrew

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Eli Zaretskii]

> Date: Sun, 19 Oct 2003 11:55:17 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> I get the feeling that the naming discussion has converged to:
> 
> 	"breakpoint" and "location"

Did it?  I (perhaps among others) suggested that, but I'm not sure
people agreed to it.

> Unlike the "user" vs "machine" I don't see us having much difficulty 
> explaining "breakpoint" and "location" to either users or developers.  Ya!

Obviously, I agree ;-)

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Sun, Oct 19, 2003 at 06:34:20PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 19 Oct 2003 11:55:17 -0400
> > From: Andrew Cagney <cagney@gnu.org>
> > 
> > I get the feeling that the naming discussion has converged to:
> > 
> > 	"breakpoint" and "location"
> 
> Did it?  I (perhaps among others) suggested that, but I'm not sure
> people agreed to it.
> 
> > Unlike the "user" vs "machine" I don't see us having much difficulty 
> > explaining "breakpoint" and "location" to either users or developers.  Ya!
> 
> Obviously, I agree ;-)

Well, I haven't seen anyone disagree.

This was a wonderfully informative, if somewhat disordered, discussion. 
I have a lot of messages flagged that I would still like to respond to,
and I think I'll try to summarize the issues and alternatives discussed
and mail them to gdb@, where this conversation should really happen.
It'll be a little while; I haven't had much time for GDB lately.

Does anyone disagree with the "breakpoint" and "location" convention
for now?  Michael, with the change from impl_breakpoint to bp_location,
are the patches I posted OK?  Just let me know if you'd like me to
update and repost them first.

I'd like to:
  - get those cleanups cleaned up and in
  - create a branch for more exploratory work; I think that to design
    anything much beyond here I'm simply going to need more
    implementation experience to talk from.
  - then raise more conversation when I have a base to work on.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Daniel Jacobowitz]

On Thu, Oct 30, 2003 at 12:49:23AM -0500, Daniel Jacobowitz wrote:
> On Sun, Oct 19, 2003 at 06:34:20PM +0200, Eli Zaretskii wrote:
> > > Date: Sun, 19 Oct 2003 11:55:17 -0400
> > > From: Andrew Cagney <cagney@gnu.org>
> > > 
> > > I get the feeling that the naming discussion has converged to:
> > > 
> > > 	"breakpoint" and "location"
> > 
> > Did it?  I (perhaps among others) suggested that, but I'm not sure
> > people agreed to it.
> > 
> > > Unlike the "user" vs "machine" I don't see us having much difficulty 
> > > explaining "breakpoint" and "location" to either users or developers.  Ya!
> > 
> > Obviously, I agree ;-)
> 
> Well, I haven't seen anyone disagree.
> 
> This was a wonderfully informative, if somewhat disordered, discussion. 
> I have a lot of messages flagged that I would still like to respond to,
> and I think I'll try to summarize the issues and alternatives discussed
> and mail them to gdb@, where this conversation should really happen.
> It'll be a little while; I haven't had much time for GDB lately.
> 
> Does anyone disagree with the "breakpoint" and "location" convention
> for now?  Michael, with the change from impl_breakpoint to bp_location,
> are the patches I posted OK?  Just let me know if you'd like me to
> update and repost them first.
> 
> I'd like to:
>   - get those cleanups cleaned up and in
>   - create a branch for more exploratory work; I think that to design
>     anything much beyond here I'm simply going to need more
>     implementation experience to talk from.
>   - then raise more conversation when I have a base to work on.

Ping.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder]

Daniel Jacobowitz wrote:

> Does anyone disagree with the "breakpoint" and "location" convention
> for now?  Michael, with the change from impl_breakpoint to bp_location,
> are the patches I posted OK?  Just let me know if you'd like me to
> update and repost them first.

Based on my following of the discussion, I'm happy to give a
'rubber stamp' approval -- but I probably should have mentioned
earlier (it slipped my mind as well) that I stepped down as
maintainer of breakpoints back in March of this year.

Maybe I better go edit the maintainers list.   ;-/

Michael