Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: "Newman,
	Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com>
Cc: gdb@sources.redhat.com
Subject: RE: filtering of commands during async operation
Date: Thu, 06 Nov 2003 16:57:00 -0000	[thread overview]
Message-ID: <16298.32136.383071.467513@localhost.redhat.com> (raw)
In-Reply-To: <F56FBA314E8E5A41895F0DA8F6716A6D02A1DF@EMSS04M11.us.lmco.com>

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
 > > 
 > > 


  reply	other threads:[~2003-11-06 16:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-06 14:32 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-06 16:57 ` Elena Zannoni [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-11-07 16:00 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-07 16:14 ` Daniel Jacobowitz
2003-11-07 17:03 ` Elena Zannoni
     [not found] <1068129153.32379.ezmlm@sources.redhat.com>
2003-11-06 17:38 ` Jim Ingham
2003-11-06 19:41   ` Elena Zannoni
2003-11-06 21:16     ` Jim Ingham
2003-11-06 22:10       ` Andrew Cagney
2003-11-06 22:29         ` Elena Zannoni
2003-11-06 22:26       ` Elena Zannoni
2003-11-05 21:11 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-05 21:52 ` Doug Evans
2003-11-05 22:00   ` Grant Edwards
2003-11-05 22:10     ` Paul Koning
2003-11-05 23:11     ` Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16298.32136.383071.467513@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=mark.newman@lmco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox