From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11050 invoked by alias); 23 Oct 2003 18:54:59 -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 11039 invoked from network); 23 Oct 2003 18:54:56 -0000 Received: from unknown (HELO grante.dsl.visi.com) (216.70.201.5) by sources.redhat.com with SMTP; 23 Oct 2003 18:54:56 -0000 Received: by grante.dsl.visi.com (Postfix, from userid 500) id 5F5013B7E3; Thu, 23 Oct 2003 14:56:54 -0400 (EDT) Date: Thu, 23 Oct 2003 18:54:00 -0000 From: Grant Edwards To: Stan Shebs Cc: gdb@sources.redhat.com Subject: Re: What does sh8 "hms" target talk to? Message-ID: <20031023185653.GA21520@grante.dsl.visi.com> References: <20031022230406.GB16318@grante.dsl.visi.com> <3F9820DA.2070709@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9820DA.2070709@apple.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00265.txt.bz2 On Thu, Oct 23, 2003 at 11:41:30AM -0700, Stan Shebs wrote: >>What, exactly, does the "hms" target expect to be talking to? > > It's looking for a human-friendly monitor; "r" for registers, "g" to > execute, etc; basically GDB acts as a fast typist. HMS is a couple > generations back, so it's unlikely that the current monitor is > sufficiently compatible. I certainly get the impression it isn't, but I haven't found it in writing yet. > >1) Current h8 eval boards ship with something called the "HDI" > > embedded monitor (or sometimes "HDI-M", which I gather is > > the same thing). Will gdb talk to that? (I'm guessing > > not.) > > At least one person (found via Google) claims that the > protocol is similar to GDB's remote protocol, so maybe "target > remote" or "target extended-remote" will work. When the board gets here, I'll give it a try, but I'm not optimistic. > Apparently HDI source is not available, which means you can't > fix target problems that come up; I'd recommend replacing with > your own stubs. Yup. That's more-or-less the conclusion to which I had come. Interestingly, the Windows-based debugger that comes with the development board is comptatible with gcc object files. Hitachi seems to have put some effort into supporting the gcc toolchain -- to the point where they even provide a HOWTO web page and a set of Gnupro tools. Both are somewhat out-of-date, but you've got to give them credit for trying. More current tools (and gdb-stubs) are availabe from Kpit-Cummins at http://www.kpitgnutools.com/. [Apparently no relation to Cummins diesel.] -- Grant Edwards grante@visi.com