From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26030 invoked by alias); 22 Sep 2003 07:14:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26022 invoked from network); 22 Sep 2003 07:14:10 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 22 Sep 2003 07:14:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C1EE12B89; Mon, 22 Sep 2003 03:14:09 -0400 (EDT) Message-ID: <3F6EA141.7020502@redhat.com> Date: Mon, 22 Sep 2003 07:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Kei Sakamoto Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] New m32r remote target, m32rsdi References: <02e201c35a5e$883a8cb0$5169910a@KEI> <20030817210347.GF11300@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00455.txt.bz2 > * remote-m32r-sdi.c : New file, interface to m32r on-chip >> debug interface, SDI (Scalable Debug Interface). >> * Makefile.in (remote-m32r-sdi.o): Add build rule. >> * config/m32r/m32r.mt (TDEPFILES) : Add remote-m32r-sdi.o. > > > I don't feel qualified to review a new remote target, so you'll have to > ask the remote maintainer. I don't feel exactly qualified either. I think, in terms of the protocol, GDB we'll have to take it at face value. Kei, Sorry for the delay, I think 6.0 is done for .... From the external interface interface viewpoint, I've noticed a few things: - it has a custom serial [socket] interface Is there a reason to not use serial.[hc]? All new targets should use a common interface (in fact I think I just deleted the last target that didn't :-) as by doing this the user gets more consistent behavior. - it isn't documented Probably just a line or two after the doco for "target m32r" in doc/gdb.texinfo. - it isn't async Look at remote.c:remote_async_wait (although as far examples go it may not help much) and notice how, for 'O' packets, it returns: /* Return immediately to the event loop. The event loop will still be waiting on the inferior afterwards. */ status->kind = TARGET_WAITKIND_IGNORE; If this target is going to last, it's going to need to eventually become async (just not immediatly). Please don't be suprized if, at some stage in the not to distant future, I start making noises about this. - it will need a brief NEWS entry! enjoy, Andrew