From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23060 invoked by alias); 16 Apr 2007 15:14:54 -0000 Received: (qmail 23051 invoked by uid 22791); 16 Apr 2007 15:14:53 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Apr 2007 16:14:51 +0100 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3GFElYf060798 for ; Mon, 16 Apr 2007 15:14:47 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3GFElBA4030546 for ; Mon, 16 Apr 2007 17:14:47 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3GFElgj011275 for ; Mon, 16 Apr 2007 17:14:47 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l3GFElrS011272; Mon, 16 Apr 2007 17:14:47 +0200 Message-Id: <200704161514.l3GFElrS011272@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 16 Apr 2007 17:14:47 +0200 Subject: Re: [rfc/rft] [3/5] Untangle register_addr: CANNOT_FETCH/STORE_REGISTER To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Mon, 16 Apr 2007 16:03:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200704142249.l3EMnlut014933@brahms.sibelius.xs4all.nl> from "Mark Kettenis" at Apr 15, 2007 12:49:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2007-04/txt/msg00251.txt.bz2 Mark Kettenis wrote: > So effectively, this turns CANNOT_FETCH_REGISTER/CANNOT_STORE_REGISTER > from being overloaded as both a native and target property into a > target-architecture-only property instead. That's probably a good > idea. Yes, that's certainly a main point of this. Having an NM file provide an override definition of a gdbarch routine is quite broken and prevents further multi-arch conversion -- fortunately the mips-linux definition of CANNOT_FETCH_REGISTER/CANNOT_STORE_REGISTER is the last remaining instance of this. > However, I think you removing the calls from the calls from the > inf_ptrace_trad_target routines is wrong. We should never fetch/store > the registers for which the target architecture says that they cannot > be fetched/stored. Hmmm. The reason why I did it this way was that I found it odd for a native target fetch_registers routine to have to rely on a gdbarch routine to make that determination. Say, suppose on a target some register cannot be fetched (or stored) by ptrace due to some limitation, but that same register may very well be accessible via a remote stub. In that case, it is not really a gdbarch property that the register isn't accessible, but should be handled solely within the native target code. Now, a native target that simply provides its own fetch_registers / store_registers *is* of course free to implement such rules on its own. My patch simply makes that same set of choices available to native targets that avail themselves of the inf_trad_ptrace helpers. Longer term, I would even think that the gdbarch cannot_store_register and cannot_fetch_register routines could be completely obsoleted -- the per-target aspects should be handled by each target itself, and the remaining per-architecture aspects could be covered by the reggroup mechanism (in particular fetch_reggroup / store_reggroup). But maybe this (if it should be the right direction anyway) should be left to another patch, and not intermixed with the other set of changes ... > If you leave them in, do any targets remain that have any registers > that can be fetched but cannot be stored by ptrace(2), that are not > defined as such by the target architecture. I'd be surprised if there > were any such registers. Well, there is the problem on mips-linux, because cannot_fetch is different from cannot_store there. However, as an intermediate step I could install the mips-linux functions as Linux-specific gdbarch callbacks instead of NM file overrides. That would affect cross-debugging too, though ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com