From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19123 invoked by alias); 13 Jul 2007 17:32:35 -0000 Received: (qmail 19115 invoked by uid 22791); 13 Jul 2007 17:32:35 -0000 X-Spam-Check-By: sourceware.org Received: from SAGW-PRIMARY.ARC.COM (HELO elsdt-razorfish.arc.com) (62.189.186.51) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jul 2007 17:32:32 +0000 Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l6DHWSPC018479; Fri, 13 Jul 2007 18:32:28 +0100 Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l6DHWSTh018477; Fri, 13 Jul 2007 18:32:28 +0100 Date: Fri, 13 Jul 2007 17:32:00 -0000 From: Joern Rennecke To: gdb@sourceware.org Subject: Re: How do I replace DEPRECATED_TM_FILE? Message-ID: <20070713173228.GC20939@elsdt-razorfish.arc.com> References: <20070621161305.GD8169@elsdt-razorfish.arc.com> <20070621162152.GA18158@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070621162152.GA18158@caradoc.them.org> User-Agent: Mutt/1.4.1i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00118.txt.bz2 On Thu, Jun 21, 2007 at 12:21:52PM -0400, Daniel Jacobowitz wrote: > Why are the register numbers different (and which register numbers)? > That determines the answer to your question. If it's the dwarf2 > mapping, for instance, you'd put overrides in an OS/ABI sniffer in the > Linux tdep file. I did some more digging, and found that apparently the dwarf register numbers start out the same, but they are translated with dwarf_reg_to_regno functions to be different. As far as I can tell, the problem stems from gdbserver coupling the target communication directly with the register cache. The register numbers that arc-linux uses are different than the hardware and the dwarf register numbers. Moreover, some registers are not accessible, and some values appear as registers that actually give a view of some of the data that is not direcly accessible: ret, orig_r8 and stop_pc. Two of the registers that are not directly accessible are ilink1 and ilink2, which contain the return from interrupt address for interrupts of level 1 and level 2, respectively. Linux saves only the return address for the previous frame, e.g. for a level 1 interrupt, it will save ilink1 in ret, and set orig_r8 to -1 to indicate that that is what is in ret. I suppose it could make sense to try to make the linux target look more like the hardware to the gdb user, by translating these values the best we can, but I don't see how this can be done with gdbserver; linux-low.c seems to assume that the linux register set and numbering must be exactly what the gdb user sees. I must admit I don't think I understand gdbserver very well yet; is there any overview of the gdbserver internals like gdbint.texinfo for the rest of gdb? Although it took me quite a while to read through that document, it left me with a better understanding (I hope) of how things are supposed to fit together in gdb (although I had to resort to grep to confirm that (and findout why) the _initialize_* functions are 'magic').