This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: filtering of commands during async operation
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: "Newman, Mark (N-Superior Technical Resource Inc)" <mark dot newman at lmco dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 6 Nov 2003 11:57:44 -0500
- Subject: RE: filtering of commands during async operation
- References: <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
> >
> >