From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1030 invoked by alias); 10 Aug 2003 20:48:18 -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 1017 invoked from network); 10 Aug 2003 20:48:14 -0000 Received: from unknown (HELO mail.inka.de) (193.197.184.2) by sources.redhat.com with SMTP; 10 Aug 2003 20:48:14 -0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19lx6r-0007WW-00; Sun, 10 Aug 2003 22:48:13 +0200 Received: from localhost (localhost [127.0.0.1]) by raven.inka.de (Postfix) with ESMTP id 2A3E61B7; Sun, 10 Aug 2003 22:47:49 +0200 (CEST) Received: by raven.inka.de (Postfix, from userid 500) id D56121B9; Sun, 10 Aug 2003 22:47:48 +0200 (CEST) Date: Sun, 10 Aug 2003 20:48:00 -0000 From: Josef Wolf To: Andreas Schwab Cc: gdb@sources.redhat.com Subject: Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3 Message-ID: <20030810204748.GA24206@raven.inka.de> References: <20030731223514.GD20282@raven.inka.de> <20030806205431.GA3349@raven.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS snapshot-20020531 X-SW-Source: 2003-08/txt/msg00124.txt.bz2 On Thu, Aug 07, 2003 at 08:08:11AM +0200, Andreas Schwab wrote: > Josef Wolf writes: > > > Ough? Does that mean that gdb should not be used to debug supervisor mode? > > GDB was designed to debug user level programs, which have no way to > see supervisor-only registers. So from GDB's point of view they don't > exist. That does not mean that GDB on m68k can not be extended to > handle them, you just need a way to get their contents from the target > (no current m68k target provides that). IMHO, seeing this registers would be a great benefit when you go behind user-only code (e.g in the embedded world). If I understand correctly, it would not be a great deal to support them. So why not to support? > By arbitrary I mean not externally imposed. The numbers are chosen > for convenience inside GDB, and exposed only to the target interface, > where they are suitably translated when communicating with the target. But this means you need to know the "inside meanings" when you want to assign different numbers. And that is exactly my problem. I don't know those "insight meanings" and I can't find any place where the "insight meanings" are described. > > BTW: I still don't have a clue what this MULTI_ARCH stuff is all about and > > how multi-arch targets are meant to be adopted. > > MULTI_ARCH means that every target architecture hooks in through the > gdbarch structure at runtime, instead of hard coding the interface > characteristics at compile time. Targets that set GDB_MULTI_ARCH to > GDB_MULTI_ARCH_PARTIAL are not quite there yet, but the basic support > is present. But then I still have no idea how to add a new MULTI_ARCH target. AFAICS the gdbarch.[ch] files are generated automatically. That introduces a lot of confusion to me. -- Please visit and sign http://petition-eurolinux.org and http://www.ffii.org -- Josef Wolf -- jw@raven.inka.de --