From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27143 invoked by alias); 15 Dec 2010 18:01:02 -0000 Received: (qmail 27084 invoked by uid 22791); 15 Dec 2010 18:01:01 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Dec 2010 18:00:56 +0000 Received: (qmail 23708 invoked from network); 15 Dec 2010 18:00:54 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Dec 2010 18:00:54 -0000 From: Pedro Alves To: Mike Frysinger Subject: Re: [PATCH v3] gdb: bfin: new port Date: Wed, 15 Dec 2010 18:01:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org References: <1291886957-12003-1-git-send-email-vapier@gentoo.org> <201012151649.32678.pedro@codesourcery.com> <201012151207.12141.vapier@gentoo.org> In-Reply-To: <201012151207.12141.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201012151800.52772.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00309.txt.bz2 On Wednesday 15 December 2010 17:07:11, Mike Frysinger wrote: > > It all looks like you should really make the PC and the CC registers > > pseudo registers handled by gdb, and not pass them on the remote > > protocol wire, getting rid of all the possibility of confusing > > out-of-sync iret/pc, astat/cc. > > the trouble with PC is that it isnt always RETI. with a Linux userspace app, > the PC is managed indirectly via RETI (by nature of the sequencer). but this > all depends on the level the remote stub is operating at. it could possibly > be indirectly handled by RETX or RETN or RETE as well. > so i think the PC > logic needs to be left up to the remote stub to properly manage. i dont think > we need to worry about people attempting to screw with any of the supervisor > level registers (RET[IXNE]) because they arent allowed to in usermode and they > make no sense unless you're in any of those contexts > (interrupt/exception/nmi/emulation). I see. Does the correct pc register depend on context (in exception, in interrupt, in normal code, in whatnot), or is it always fixed per stub? If the latter, it sounds like something that should be handled by a xml target description that somehow tells gdb which register is the pc (sounds more complicated than it is, I think). If the former, is there any way to tell which is the correct register by reading some other register, perhaps? Otherwise, yeah, best keep it a separate register, which is a bit of a shame... -- Pedro Alves