RE: filtering of commands during async operation

RE: filtering of commands during async operation

[Newman, Mark (N-Superior Technical Resource Inc)]

> From: Elena Zannoni [mailto:ezannoni@redhat.com]
.....
> 
>  > Next a request - Could you add "tfind", "tdump", "tstart", 
> and "tstop"
>  > to the list of acceptable commands?  I know that if I am using
>  > tracepoints to monitor what is going on in a system I 
> don't want to wait
>  > and hope that whatever event I am monitoring for occurs.  
> I want to be
>  > able to look at the tracepoints while they are occurring.
>  > 
> 
> 
> It sounds like a sensible change, however I'd like to know a bit more
> about the direction you are headed. Surely such a change would be a
> candidate for a patch.
> 

I am not certain what you mean by where I am headed.  My near term
objective is to get tracepoints running in the background and to provide
some additions that I typically put in a debugger. 

I added some support for tracepoints in gdbserver.  I then tested that
in the foreground.  It seemed that everyone writing to the lists at the
time was doing that. That resulted in couple (3) of bug finds that were
fixed.

I provided a patch and a bug report (actually an enhancement - which I
cannot find now) that allows tracepoints to run while in async mode.  I
am now looking at running tracepoints in the background.  That resulted
in this thread.

I am headed at getting tracepoints to the point where I can start a
remote target running, establish tracepoints, and then go in and peek
and poke through those tracepoints without disturbing the remote process
(as Jim's and Michael's Heisenberg paper talked about).  I am trying to
go a step further than their paper by allowing one to inspect the
tracepoints while the remote is running, collecting, and hopefully not
being perturbed.  This is something I have done in the past with some
commercial debuggers and I am tired of doing and redoing it.

I have typically used this type of analysis on systems that incorporate
multiple computers - possibly multiple cpu's with multiple dsp's -
frequently these processors are headless.  Tracepoints or something like
them are used to help isolate a problem (feature) to a specific process
on a specific processor.  Then and if needed the more classic features
of a debugger are used to reduce the error. 

>  > Finally - would it be better to place a flag in 
> command_list_element and
>  > avoid all of the strcmp's altogether?
>  > 
> 
> The async interface was not really fully implemented, and the current
> subset of commands to be run while the inferior executes was just a
> proof of concept. 

I have been sorta following the thread between Andrew, Jim, and Elena.
I would very much like to get any changes that have been made to async.
I assume that other people would also.  If I can't then, as you
suggested Elena, I will simply have to duplicate the work that Apple
did.

It may very well be that I am not the only person to find the problem
but rather the only one to report it.  The effect of the problem was to
let all commands go through.

I have only a short history in this list and it is not clear to me.
Have the Apple changes been delivered?  Has the first of two sets of
changes only been delivered?  Is Jim going to make those changes that
Apple made available?  Are the Apple changes available in source with
Panther?

Re: filtering of commands during async operation

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 11:00:20AM -0500, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> 
> 
> > From: Elena Zannoni [mailto:ezannoni@redhat.com]
> .....
> > 
> >  > Next a request - Could you add "tfind", "tdump", "tstart", 
> > and "tstop"
> >  > to the list of acceptable commands?  I know that if I am using
> >  > tracepoints to monitor what is going on in a system I 
> > don't want to wait
> >  > and hope that whatever event I am monitoring for occurs.  
> > I want to be
> >  > able to look at the tracepoints while they are occurring.
> >  > 
> > 
> > 
> > It sounds like a sensible change, however I'd like to know a bit more
> > about the direction you are headed. Surely such a change would be a
> > candidate for a patch.
> > 
> 
> I am not certain what you mean by where I am headed.  My near term
> objective is to get tracepoints running in the background and to provide
> some additions that I typically put in a debugger. 
> 
> I added some support for tracepoints in gdbserver.  I then tested that
> in the foreground.  It seemed that everyone writing to the lists at the
> time was doing that. That resulted in couple (3) of bug finds that were
> fixed.
> 
> I provided a patch and a bug report (actually an enhancement - which I
> cannot find now) that allows tracepoints to run while in async mode.  I
> am now looking at running tracepoints in the background.  That resulted
> in this thread.
> 
> I am headed at getting tracepoints to the point where I can start a
> remote target running, establish tracepoints, and then go in and peek
> and poke through those tracepoints without disturbing the remote process
> (as Jim's and Michael's Heisenberg paper talked about).  I am trying to
> go a step further than their paper by allowing one to inspect the
> tracepoints while the remote is running, collecting, and hopefully not
> being perturbed.  This is something I have done in the past with some
> commercial debuggers and I am tired of doing and redoing it.

Hi Mark,

Are you planning to also contribute the gdbserver support for these
feature?  I'd love to see it added.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: filtering of commands during async operation

[Elena Zannoni]

Newman, Mark (N-Superior Technical Resource Inc) writes:
 > 
 > 
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com]
 > .....
 > > 
 > >  > Next a request - Could you add "tfind", "tdump", "tstart", 
 > > and "tstop"
 > >  > to the list of acceptable commands?  I know that if I am using
 > >  > tracepoints to monitor what is going on in a system I 
 > > don't want to wait
 > >  > and hope that whatever event I am monitoring for occurs.  
 > > I want to be
 > >  > able to look at the tracepoints while they are occurring.
 > >  > 
 > > 
 > > 
 > > It sounds like a sensible change, however I'd like to know a bit more
 > > about the direction you are headed. Surely such a change would be a
 > > candidate for a patch.
 > > 
 > 
 > I am not certain what you mean by where I am headed.  My near term
 > objective is to get tracepoints running in the background and to provide
 > some additions that I typically put in a debugger. 
 > 
 > I added some support for tracepoints in gdbserver.  I then tested that
 > in the foreground.  It seemed that everyone writing to the lists at the
 > time was doing that. That resulted in couple (3) of bug finds that were
 > fixed.
 > 
 > I provided a patch and a bug report (actually an enhancement - which I
 > cannot find now) that allows tracepoints to run while in async mode.  I
 > am now looking at running tracepoints in the background.  That resulted
 > in this thread.
 > 

I found some messages/patches and reread your postings. I now see what
you want to do.

 > I am headed at getting tracepoints to the point where I can start a
 > remote target running, establish tracepoints, and then go in and peek
 > and poke through those tracepoints without disturbing the remote process
 > (as Jim's and Michael's Heisenberg paper talked about).  I am trying to
 > go a step further than their paper by allowing one to inspect the
 > tracepoints while the remote is running, collecting, and hopefully not
 > being perturbed.  This is something I have done in the past with some
 > commercial debuggers and I am tired of doing and redoing it.
 > 

OK.

 > I have typically used this type of analysis on systems that incorporate
 > multiple computers - possibly multiple cpu's with multiple dsp's -
 > frequently these processors are headless.  Tracepoints or something like
 > them are used to help isolate a problem (feature) to a specific process
 > on a specific processor.  Then and if needed the more classic features
 > of a debugger are used to reduce the error. 
 > 
 > >  > Finally - would it be better to place a flag in 
 > > command_list_element and
 > >  > avoid all of the strcmp's altogether?
 > >  > 
 > > 
 > > The async interface was not really fully implemented, and the current
 > > subset of commands to be run while the inferior executes was just a
 > > proof of concept. 
 > 
 > I have been sorta following the thread between Andrew, Jim, and Elena.
 > I would very much like to get any changes that have been made to async.
 > I assume that other people would also.  If I can't then, as you
 > suggested Elena, I will simply have to duplicate the work that Apple
 > did.
 > 

Yeah, it would be nice to see what Apple did.

 > It may very well be that I am not the only person to find the problem
 > but rather the only one to report it.  The effect of the problem was to
 > let all commands go through.
 > 

Proabably you are right, sigh. Apple very likely ran into that as
well.

 > I have only a short history in this list and it is not clear to me.
 > Have the Apple changes been delivered?  Has the first of two sets of
 > changes only been delivered?  Is Jim going to make those changes that
 > Apple made available?  Are the Apple changes available in source with
 > Panther?

Apple definitely makes their sources available, somewhere on their
website, but I am not sure where. I remember that finding them was not
very straightforward.

elena

Re: filtering of commands during async operation

[Jim Ingham]

The all the targets we support in Apple's  version of gdb are async - 
including the Mach-O native target.  It took a bunch of mucking around 
to get it working (and to get things like commands that run the target 
working).  And I am pretty sure that I broke the remote async in the 
process, however, there were a couple of hacks in there (marked as such 
in the code) that messed us up and I didn't have the patience at the 
time to make both work...

So I would need to do some clean-up before our code would be ready for 
submission, but as a proof of concept it might be useful to folks, and 
in our system it works pretty well.

Jim

On Nov 6, 2003, at 6:32 AM, gdb-digest-help@sources.redhat.com wrote:

> Whoops. I agree, this is screwed up.  I'll just make the fix now, no
> need to file a bug report.  I am curious, did somebody get async
> native to work? So far there is only the remote async target.  I do
> remember testing this, back 4 years ago, maybe the logic got turned
> around at some point.
>
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: filtering of commands during async operation

[Elena Zannoni]

Jim Ingham writes:
 > The all the targets we support in Apple's  version of gdb are async - 
 > including the Mach-O native target.  It took a bunch of mucking around 
 > to get it working (and to get things like commands that run the target 
 > working).  And I am pretty sure that I broke the remote async in the 
 > process, however, there were a couple of hacks in there (marked as such 
 > in the code) that messed us up and I didn't have the patience at the 
 > time to make both work...
 > 
 > So I would need to do some clean-up before our code would be ready for 
 > submission, but as a proof of concept it might be useful to folks, and 
 > in our system it works pretty well.
 > 

It seems to have become some kind of a pattern that somebody other
than Apple is going to merge Apple's changes with the FSF mainline.  Is
there any way to get another snapshot/tarball (like it was done in Dec
2001)?  Maybe somebody will volunteer, even though this approach is
suboptimal.

elena



 > Jim
 > 
 > On Nov 6, 2003, at 6:32 AM, gdb-digest-help@sources.redhat.com wrote:
 > 
 > > Whoops. I agree, this is screwed up.  I'll just make the fix now, no
 > > need to file a bug report.  I am curious, did somebody get async
 > > native to work? So far there is only the remote async target.  I do
 > > remember testing this, back 4 years ago, maybe the logic got turned
 > > around at some point.
 > >
 > >
 > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
 > Jim Ingham                                                           
 > jingham@apple.com
 > Developer Tools - gdb

Re: filtering of commands during async operation

[Jim Ingham]

Elena,

On Nov 6, 2003, at 11:41 AM, Elena Zannoni wrote:

> Jim Ingham writes:
>> The all the targets we support in Apple's  version of gdb are async -
>> including the Mach-O native target.  It took a bunch of mucking around
>> to get it working (and to get things like commands that run the target
>> working).  And I am pretty sure that I broke the remote async in the
>> process, however, there were a couple of hacks in there (marked as 
>> such
>> in the code) that messed us up and I didn't have the patience at the
>> time to make both work...
>>
>> So I would need to do some clean-up before our code would be ready for
>> submission, but as a proof of concept it might be useful to folks, and
>> in our system it works pretty well.
>>
>
> It seems to have become some kind of a pattern that somebody other
> than Apple is going to merge Apple's changes with the FSF mainline.  Is
> there any way to get another snapshot/tarball (like it was done in Dec
> 2001)?  Maybe somebody will volunteer, even though this approach is
> suboptimal.
>

We had one brief period where we got a little time to try merging 
sources, but that passed without much result, and I don't see us 
getting another chance in the near future.

The last time we did a tarball drop it meant that Adam ended up wasting 
time merging old ObjC code into the TOT gdb - work which we had already 
done on our branch.  It would be great not to do that again...

Jim


> elena
>
>
>
>> Jim
>>
>> On Nov 6, 2003, at 6:32 AM, gdb-digest-help@sources.redhat.com wrote:
>>
>>> Whoops. I agree, this is screwed up.  I'll just make the fix now, no
>>> need to file a bug report.  I am curious, did somebody get async
>>> native to work? So far there is only the remote async target.  I do
>>> remember testing this, back 4 years ago, maybe the logic got turned
>>> around at some point.
>>>
>>>
>> _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>> Jim Ingham
>> jingham@apple.com
>> Developer Tools - gdb
>>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: filtering of commands during async operation

[Andrew Cagney]

> The last time we did a tarball drop it meant that Adam ended up wasting time merging old ObjC code into the TOT gdb - work which we had already done on our branch.  It would be great not to do that again...

Adam has been quietly integrating/overhauling that very old objective-c 
code, and that work is still ongoing:
http://sources.redhat.com/ml/gdb-patches/2003-10/msg00581.html
What Adam did was definitly not a merge.

Andrew

Re: filtering of commands during async operation

[Elena Zannoni]

Andrew Cagney writes:
 > > The last time we did a tarball drop it meant that Adam ended up wasting time merging old ObjC code into the TOT gdb - work which we had already done on our branch.  It would be great not to do that again...
 > 
 > Adam has been quietly integrating/overhauling that very old objective-c 
 > code, and that work is still ongoing:
 > http://sources.redhat.com/ml/gdb-patches/2003-10/msg00581.html
 > What Adam did was definitly not a merge.
 > 
 > Andrew
 > 

Oh, you are right. I used the wrong term. It was not a 'merge' in the
proper sense of the word.  Much was rewritten.

elena

Re: filtering of commands during async operation

[Elena Zannoni]

Jim Ingham writes:
 > Elena,
 > 
 > On Nov 6, 2003, at 11:41 AM, Elena Zannoni wrote:
 > 
 > > Jim Ingham writes:
 > >> The all the targets we support in Apple's  version of gdb are async -
 > >> including the Mach-O native target.  It took a bunch of mucking around
 > >> to get it working (and to get things like commands that run the target
 > >> working).  And I am pretty sure that I broke the remote async in the
 > >> process, however, there were a couple of hacks in there (marked as 
 > >> such
 > >> in the code) that messed us up and I didn't have the patience at the
 > >> time to make both work...
 > >>
 > >> So I would need to do some clean-up before our code would be ready for
 > >> submission, but as a proof of concept it might be useful to folks, and
 > >> in our system it works pretty well.
 > >>
 > >
 > > It seems to have become some kind of a pattern that somebody other
 > > than Apple is going to merge Apple's changes with the FSF mainline.  Is
 > > there any way to get another snapshot/tarball (like it was done in Dec
 > > 2001)?  Maybe somebody will volunteer, even though this approach is
 > > suboptimal.
 > >
 > 
 > We had one brief period where we got a little time to try merging 
 > sources, but that passed without much result, and I don't see us 
 > getting another chance in the near future.

Exactly, that's why I said that somebody else will be more likely to
do it.

 > 
 > The last time we did a tarball drop it meant that Adam ended up wasting 
 > time merging old ObjC code into the TOT gdb - work which we had already 
 > done on our branch.  It would be great not to do that again...
 > 

the objc support is in gdb mainline and it has been there for a while.
There are some bugs still, but it was merged.
Are you referring to something else?

Same story for the interpreter stuff which Keith, Andrew and I merged.

I think we went through this before, with the previoius tarball.  If
it's too hard a requirement, then let's forget about it. We'll live
with the status quo. 

elena

 > Jim
 > 
 > 
 > > elena
 > >
 > >
 > >
 > >> Jim
 > >>
 > >> On Nov 6, 2003, at 6:32 AM, gdb-digest-help@sources.redhat.com wrote:
 > >>
 > >>> Whoops. I agree, this is screwed up.  I'll just make the fix now, no
 > >>> need to file a bug report.  I am curious, did somebody get async
 > >>> native to work? So far there is only the remote async target.  I do
 > >>> remember testing this, back 4 years ago, maybe the logic got turned
 > >>> around at some point.
 > >>>
 > >>>
 > >> _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
 > >> Jim Ingham
 > >> jingham@apple.com
 > >> Developer Tools - gdb
 > >>
 > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
 > Jim Ingham                                                           
 > jingham@apple.com
 > Developer Tools - gdb

RE: filtering of commands during async operation

[Newman, Mark (N-Superior Technical Resource Inc)]

Three things 

To answer your question about async native I am working on all aspects
of async - however at the current time I am concentrating on remote with
tracepoints.

Next a request - Could you add "tfind", "tdump", "tstart", and "tstop"
to the list of acceptable commands?  I know that if I am using
tracepoints to monitor what is going on in a system I don't want to wait
and hope that whatever event I am monitoring for occurs.  I want to be
able to look at the tracepoints while they are occurring.

Finally - would it be better to place a flag in command_list_element and
avoid all of the strcmp's altogether?

                                         Mark Newman

> -----Original Message-----
> From: Elena Zannoni [mailto:ezannoni@redhat.com]
> Sent: Wednesday, November 05, 2003 6:12 PM
> To: Grant Edwards
> Cc: Doug Evans; Newman, Mark (N-Superior Technical Resource Inc);
> gdb@sources.redhat.com
> Subject: Re: filtering of commands during async operation
> 
> 
> Grant Edwards writes:
>  > 
>  > > Good example of why it's useful to avoid using ! with strcmp.
>  > > 
>  > >  > The code should be:
>  > >  > 
>  > >  > if (event_loop_p && target_can_async_p () && 
> target_executing) {
>  > >  >    if (!(strcmp (c->name, "help") == 0)
>  > >  > 	    && !(strcmp (c->name, "pwd") == 0)
>  > >  > 	    && !(strcmp (c->name, "show") == 0)
>  > >  > 	    && !(strcmp (c->name, "stop") == 0)) {
>  > >  >    error ("Cannot execute this command while the 
> target is running.");
>  > >  >    }
>  > >  > }
>  > >  > 
>  > >  > Unless someone objects I am going to put in a bug 
> report and a patch.
>  > > 
>  > > Why not just strcmp () != 0
>  > 
>  > Why not just strcmp() ?
>  > 
>  >   if (strcmp() 
>  >       && strcmp() 
>  >       && strcmp())
>  > 
> 
> Whoops. I agree, this is screwed up.  I'll just make the fix now, no
> need to file a bug report.  I am curious, did somebody get async
> native to work? So far there is only the remote async target.  I do
> remember testing this, back 4 years ago, maybe the logic got turned
> around at some point.
> 
> I think strcmp != 0 is ok. It is the preferred form in gdb.  Is
> this in the ARI? mmmm... partially it is. It is not flagged in the
> counts though.
> 
> elena
> 
> 

RE: filtering of commands during async operation

[Elena Zannoni]

Newman, Mark (N-Superior Technical Resource Inc) writes:
 > Three things 
 > 
 > To answer your question about async native I am working on all aspects
 > of async - however at the current time I am concentrating on remote with
 > tracepoints.
 > 

Great!
If you consider contributing your work, which would be nice, make sure
you have a copyright assignment in place, otherwise your patches cannot
be considered for inclusion.

 > Next a request - Could you add "tfind", "tdump", "tstart", and "tstop"
 > to the list of acceptable commands?  I know that if I am using
 > tracepoints to monitor what is going on in a system I don't want to wait
 > and hope that whatever event I am monitoring for occurs.  I want to be
 > able to look at the tracepoints while they are occurring.
 > 


It sounds like a sensible change, however I'd like to know a bit more
about the direction you are headed. Surely such a change would be a
candidate for a patch.

 > Finally - would it be better to place a flag in command_list_element and
 > avoid all of the strcmp's altogether?
 > 

The async interface was not really fully implemented, and the current
subset of commands to be run while the inferior executes was just a
proof of concept. Similarly the way this was achieved was also a proof
of concept kind of thing, and indeed you are the first one in 4 years
to discover that it really didn't work as intended.  Having a flag in
the command structure is in the right direction, but as I said above
it would be best to address more general issues with the async
interface first (for instance I know that Apple had to make changes to
the event loop and such to make async work with natives).  Feel free
to start a discussion on this mailing list or/and start contributing
patches.

elena


 >                                          Mark Newman
 > 
 > > -----Original Message-----
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com]
 > > Sent: Wednesday, November 05, 2003 6:12 PM
 > > To: Grant Edwards
 > > Cc: Doug Evans; Newman, Mark (N-Superior Technical Resource Inc);
 > > gdb@sources.redhat.com
 > > Subject: Re: filtering of commands during async operation
 > > 
 > > 
 > > Grant Edwards writes:
 > >  > 
 > >  > > Good example of why it's useful to avoid using ! with strcmp.
 > >  > > 
 > >  > >  > The code should be:
 > >  > >  > 
 > >  > >  > if (event_loop_p && target_can_async_p () && 
 > > target_executing) {
 > >  > >  >    if (!(strcmp (c->name, "help") == 0)
 > >  > >  > 	    && !(strcmp (c->name, "pwd") == 0)
 > >  > >  > 	    && !(strcmp (c->name, "show") == 0)
 > >  > >  > 	    && !(strcmp (c->name, "stop") == 0)) {
 > >  > >  >    error ("Cannot execute this command while the 
 > > target is running.");
 > >  > >  >    }
 > >  > >  > }
 > >  > >  > 
 > >  > >  > Unless someone objects I am going to put in a bug 
 > > report and a patch.
 > >  > > 
 > >  > > Why not just strcmp () != 0
 > >  > 
 > >  > Why not just strcmp() ?
 > >  > 
 > >  >   if (strcmp() 
 > >  >       && strcmp() 
 > >  >       && strcmp())
 > >  > 
 > > 
 > > Whoops. I agree, this is screwed up.  I'll just make the fix now, no
 > > need to file a bug report.  I am curious, did somebody get async
 > > native to work? So far there is only the remote async target.  I do
 > > remember testing this, back 4 years ago, maybe the logic got turned
 > > around at some point.
 > > 
 > > I think strcmp != 0 is ok. It is the preferred form in gdb.  Is
 > > this in the ARI? mmmm... partially it is. It is not flagged in the
 > > counts though.
 > > 
 > > elena
 > > 
 > > 

filtering of commands during async operation

[Newman, Mark (N-Superior Technical Resource Inc)]

In top.c there is an attempt to filter what commands can be issued during async operation.  That code is not filtering (at least under RH on an Intel box).  The code is

if (event_loop_p && target_can_async_p () && target_executing)
if (!strcmp (c->name, "help")
	    && !strcmp (c->name, "pwd")
	    && !strcmp (c->name, "show")
	    && !strcmp (c->name, "stop"))
error ("Cannot execute this command while the target is running.");


The code should be:

if (event_loop_p && target_can_async_p () && target_executing) {
   if (!(strcmp (c->name, "help") == 0)
	    && !(strcmp (c->name, "pwd") == 0)
	    && !(strcmp (c->name, "show") == 0)
	    && !(strcmp (c->name, "stop") == 0)) {
   error ("Cannot execute this command while the target is running.");
   }
}

Unless someone objects I am going to put in a bug report and a patch.

In addition I would like to set up a more flexible way of defining which commands are legal while target_executing == 1 and in async mode.

                                        Mark Newman

filtering of commands during async operation

[Doug Evans]

Newman, Mark (N-Superior Technical Resource Inc) writes:
 > 
 > In top.c there is an attempt to filter what commands can be issued during async operation.  That code is not filtering (at least under RH on an Intel box).  The code is
 > 
 > if (event_loop_p && target_can_async_p () && target_executing)
 > if (!strcmp (c->name, "help")
 > 	    && !strcmp (c->name, "pwd")
 > 	    && !strcmp (c->name, "show")
 > 	    && !strcmp (c->name, "stop"))
 > error ("Cannot execute this command while the target is running.");

Good example of why it's useful to avoid using ! with strcmp.

 > The code should be:
 > 
 > if (event_loop_p && target_can_async_p () && target_executing) {
 >    if (!(strcmp (c->name, "help") == 0)
 > 	    && !(strcmp (c->name, "pwd") == 0)
 > 	    && !(strcmp (c->name, "show") == 0)
 > 	    && !(strcmp (c->name, "stop") == 0)) {
 >    error ("Cannot execute this command while the target is running.");
 >    }
 > }
 > 
 > Unless someone objects I am going to put in a bug report and a patch.

Why not just strcmp () != 0

Re: filtering of commands during async operation

[Grant Edwards]

> Good example of why it's useful to avoid using ! with strcmp.
> 
>  > The code should be:
>  > 
>  > if (event_loop_p && target_can_async_p () && target_executing) {
>  >    if (!(strcmp (c->name, "help") == 0)
>  > 	    && !(strcmp (c->name, "pwd") == 0)
>  > 	    && !(strcmp (c->name, "show") == 0)
>  > 	    && !(strcmp (c->name, "stop") == 0)) {
>  >    error ("Cannot execute this command while the target is running.");
>  >    }
>  > }
>  > 
>  > Unless someone objects I am going to put in a bug report and a patch.
> 
> Why not just strcmp () != 0

Why not just strcmp() ?

  if (strcmp() 
      && strcmp() 
      && strcmp())

-- 
Grant Edwards
grante@visi.com

Re: filtering of commands during async operation

[Paul Koning]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

 >> Good example of why it's useful to avoid using ! with strcmp.

 Grant> Why not just strcmp() ?

 Grant> if (strcmp() && strcmp() && strcmp())

Because strcmp isn't a boolean function.  Using boolean operations on
non-boolean values is a great way to produce bugs (as the example
showed).  It has a precise meaning in C, but that doesn't mean it
should be done.

       paul

Re: filtering of commands during async operation

[Elena Zannoni]

Grant Edwards writes:
 > 
 > > Good example of why it's useful to avoid using ! with strcmp.
 > > 
 > >  > The code should be:
 > >  > 
 > >  > if (event_loop_p && target_can_async_p () && target_executing) {
 > >  >    if (!(strcmp (c->name, "help") == 0)
 > >  > 	    && !(strcmp (c->name, "pwd") == 0)
 > >  > 	    && !(strcmp (c->name, "show") == 0)
 > >  > 	    && !(strcmp (c->name, "stop") == 0)) {
 > >  >    error ("Cannot execute this command while the target is running.");
 > >  >    }
 > >  > }
 > >  > 
 > >  > Unless someone objects I am going to put in a bug report and a patch.
 > > 
 > > Why not just strcmp () != 0
 > 
 > Why not just strcmp() ?
 > 
 >   if (strcmp() 
 >       && strcmp() 
 >       && strcmp())
 > 

Whoops. I agree, this is screwed up.  I'll just make the fix now, no
need to file a bug report.  I am curious, did somebody get async
native to work? So far there is only the remote async target.  I do
remember testing this, back 4 years ago, maybe the logic got turned
around at some point.

I think strcmp != 0 is ok. It is the preferred form in gdb.  Is
this in the ARI? mmmm... partially it is. It is not flagged in the
counts though.

elena