question about -file-exec-and-symbols gdbmi command

Hello folks,

I am using  gdb with the mi2 interpreter.

I do -file-exec-and-symbols <prog-1>, set a couple of
breakpoints, do a bit of debugging a bit etc.

Then I do a -file-exec-and-symbols <prog-2> .
At this point, gdb tries to set the breakpoint I have set
previously,
while debugging <prog-1>. Of course, that attempt
fails. Is this
behavious normal ? I would have thought that gdb should
clear the
current breakpoints when -file-exec-and-symbols is run on a
new exec
file.

Also, is there an irc channel (or jabber room) where the gdb
developers
can be reached ? This is typically the case of small stuff
some people
(like me) would love sending a patch for. And having the
developpers at
hand to ask some questions quickly like -  "where is
function to look at
to clear the breakpoints ?" where the function called
by
"-file-exec-and-symbols to actually do the work ?"
- would help a lot
to increase the mindshare of GDB internals.


Cheers,



-- 
Dodji Seketeli
http://www.seketeli.org
/dodji

 > I am using  gdb with the mi2 interpreter.
 > 
 > I do -file-exec-and-symbols <prog-1>, set a
couple of
 > breakpoints, do a bit of debugging a bit etc.
 > 
 > Then I do a -file-exec-and-symbols <prog-2> .
 > At this point, gdb tries to set the breakpoint I have
set previously,
 > while debugging <prog-1>. Of course, that
attempt fails. Is this
 > behavious normal ? I would have thought that gdb
should clear the
 > current breakpoints when -file-exec-and-symbols is run
on a new exec
 > file.

-file-exec-and-symbols is really just the `file' command:

In mi-cmds.c:

  { "file-exec-and-symbols", { "file", 1
}, NULL, NULL },

so it's not restricted to MI.

I don't really use either but maybe it would be inconvenient
to have all
the breakpoints cleared, if you wanted to switch to another
version of the
same program, say.  It's easier to delete then all manually,
just with `delete'
than it is to add them back again.

Perhaps it could be a GDB option.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Wed, 18 Apr 2007 21:58:49 +1200
Nick Roberts <nickrobsnap.net.nz> wrote:

[...]

> -file-exec-and-symbols is really just the `file'
command:
> 
> In mi-cmds.c:
> 
>   { "file-exec-and-symbols", {
"file", 1 }, NULL, NULL },
> 
> so it's not restricted to MI.
> 
> I don't really use either but maybe it would be
inconvenient to have
> all the breakpoints cleared, if you wanted to switch to
another
> version of the same program, say.  It's easier to
delete then all
> manually, just with `delete' than it is to add them
back again.
> 
> Perhaps it could be a GDB option.

Okay thank you for the hints, Nick.

I maybe I could try a patch that introduces a new command
that clears
all the breakpoints when you load a new file ?

Cheers,


-- 
Dodji Seketeli
http://www.seketeli.org
/dodji

 > > Perhaps it could be a GDB option.
 > 
 > Okay thank you for the hints, Nick.
 > 
 > I maybe I could try a patch that introduces a new
command that clears
 > all the breakpoints when you load a new file ?

I was thinking modifying the GDB environment with the set
command, e.g.,

set breakpoint auto-clear on/off

I think a new command would make behaviour hard to toggle,
with a front end
say.

I can't approve your patches, so don't do anything yet. 
Wait for Daniel
Jacobowitz, for example, to give his opinion.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Wed, Apr 18, 2007 at 10:36:37PM +1200, Nick Roberts
wrote:
>  > > Perhaps it could be a GDB option.
>  > 
>  > Okay thank you for the hints, Nick.
>  > 
>  > I maybe I could try a patch that introduces a new
command that clears
>  > all the breakpoints when you load a new file ?
> 
> I was thinking modifying the GDB environment with the
set command, e.g.,
> 
> set breakpoint auto-clear on/off
> 
> I think a new command would make behaviour hard to
toggle, with a front end
> say.
> 
> I can't approve your patches, so don't do anything yet.
 Wait for Daniel
> Jacobowitz, for example, to give his opinion.

I don't see the point.  If you want to delete breakpoints
when you
load a new file, why not just do so?  It's easy with
-break-list and
-break-delete.

It shouldn't happen automatically.  For instance, one use
of
-file-exec-and-symbols is to tell GDB that the file has been
recompiled.

-- 
Daniel Jacobowitz
CodeSourcery

 > >  > I maybe I could try a patch that introduces
a new command that clears
 > >  > all the breakpoints when you load a new
file ?
 > > 
 > > I was thinking modifying the GDB environment with
the set command, e.g.,
 > > 
 > > set breakpoint auto-clear on/off
 > > 
 > > I think a new command would make behaviour hard
to toggle, with a front end
 > > say.
 > > 
 > > I can't approve your patches, so don't do
anything yet.  Wait for Daniel
 > > Jacobowitz, for example, to give his opinion.
 > 
 > I don't see the point.  If you want to delete
breakpoints when you
 > load a new file, why not just do so?  It's easy with
-break-list and
 > -break-delete.

I'm thinking that if you load a new program into a front
end, there's no need
to restart GDB, and the user might be surprised to see his
old breakpoints are
still there.  I don't have DDD or Insight to hand to see
what they do.

 > It shouldn't happen automatically.  For instance, one
use of
 > -file-exec-and-symbols is to tell GDB that the file
has been recompiled.

That's independent of the breakpoint issue, isn't it?

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Wed, Apr 18, 2007 at 11:59:47PM +1200, Nick Roberts
wrote:
>  > I don't see the point.  If you want to delete
breakpoints when you
>  > load a new file, why not just do so?  It's easy
with -break-list and
>  > -break-delete.
> 
> I'm thinking that if you load a new program into a
front end, there's no need
> to restart GDB, and the user might be surprised to see
his old breakpoints are
> still there.  I don't have DDD or Insight to hand to
see what they do.
> 
>  > It shouldn't happen automatically.  For instance,
one use of
>  > -file-exec-and-symbols is to tell GDB that the
file has been recompiled.
> 
> That's independent of the breakpoint issue, isn't it?

Nope.  The difference is that the front end has some
knowledge of
"this is a new program" versus "this is the
same program being
reloaded", because it issued the command in response to
some user
stimulus.  GDB has no way to know why the command was
issued; in one
case deleting breakpoints is appropriate, in the other it is
not.

So if the front end wants breakpoints deleted, I think it's
reasonable
for it to do so explicitly.

-- 
Daniel Jacobowitz
CodeSourcery

On Wed, 18 Apr 2007 08:11:37 -0400
Daniel Jacobowitz <drowfalse.org> wrote:

> Nope.  The difference is that the front end has some
knowledge of
> "this is a new program" versus "this is
the same program being
> reloaded", because it issued the command in
response to some user
> stimulus.  GDB has no way to know why the command was
issued; in one
> case deleting breakpoints is appropriate, in the other
it is not.
> 
> So if the front end wants breakpoints deleted, I think
it's reasonable
> for it to do so explicitly.

Indeed. I noticed this whilst writing a front end, actually.
I got
hard time fuguring why I was seeing breakpoints from another
binary
being returned by -break-list 

I understand your point and felt back on what you suggest.

Thank you for that.

So, there is no IRC channel where you guys can be reached ?


Cheers,


-- 
Dodji Seketeli
http://www.seketeli.org
/dodji

On Wed, Apr 18, 2007 at 03:06:15PM +0200, Dodji Seketeli
wrote:
> So, there is no IRC channel where you guys can be
reached ? 

No, generally there isn't.

-- 
Daniel Jacobowitz
CodeSourcery

 > >  > It shouldn't happen automatically.  For
instance, one use of
 > >  > -file-exec-and-symbols is to tell GDB that
the file has been
 > >  > recompiled.
 > > 
 > > That's independent of the breakpoint issue, isn't
it?
 > 
 > Nope.  The difference is that the front end has some
knowledge of
 > "this is a new program" versus "this is
the same program being
 > reloaded", because it issued the command in
response to some user
 > stimulus.  GDB has no way to know why the command was
issued; in one
 > case deleting breakpoints is appropriate, in the other
it is not.
 > 
 > So if the front end wants breakpoints deleted, I think
it's reasonable
 > for it to do so explicitly.

In Emacs at least, GDB command can be entered through the
GUD buffer, just like
they are on the command line, so I don't see how it would
know the user's
purpose any more than GDB does.  Anyway, I have no need of
this functionality
at the moment.  I'll raise it again when, or if, I need it
later



-- 
Nick                                           http://www.inet.net.n
z/~nickrob