From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19048 invoked by alias); 6 Nov 2003 16:57:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19041 invoked from network); 6 Nov 2003 16:57:45 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 6 Nov 2003 16:57:45 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 9C57A1A4291; Thu, 6 Nov 2003 11:57:44 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16298.32136.383071.467513@localhost.redhat.com> Date: Thu, 06 Nov 2003 16:57:00 -0000 To: "Newman, Mark (N-Superior Technical Resource Inc)" Cc: gdb@sources.redhat.com Subject: RE: filtering of commands during async operation In-Reply-To: References: X-SW-Source: 2003-11/txt/msg00052.txt.bz2 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 > > > >