From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5970 invoked by alias); 1 May 2007 01:26:16 -0000 Received: (qmail 5961 invoked by uid 22791); 1 May 2007 01:26:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 May 2007 02:26:13 +0100 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l411Q8fJ088096 for ; Tue, 1 May 2007 01:26:08 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 l411Q8Up3596352 for ; Tue, 1 May 2007 03:26:08 +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 l411Q8vV016560 for ; Tue, 1 May 2007 03:26:08 +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 l411Q814016557 for ; Tue, 1 May 2007 03:26:08 +0200 Message-Id: <200705010126.l411Q814016557@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 1 May 2007 03:26:04 +0200 Subject: [rfc] [00/14] Push REGCACHE into target_fetch/store_registers To: gdb-patches@sourceware.org Date: Tue, 01 May 2007 01:26:00 -0000 From: "Ulrich Weigand" 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-05/txt/msg00000.txt.bz2 Hello, one problem with using multiple gdbarch's at the same time is the notion of "swapped" gdbarch data. It really isn't safe to use any other gdbarch but current_gdbarch as long as we still have those. One particular important piece of such data is the global "current_regcache". The following set of patches takes one step towards eliminating that global, which would also make real per-thread register caches possible at some time. Specifically, the patch adds a REGCACHE argument to the to_fetch_registers and to_store_registers target operations, and uses that to eliminate use of current_regcache in all implementation of those operations. As the core file target implements to_fetch_registers, this means that the core_read_registers core_fns callback also needs a REGCACHE parameter. As core-regset.o implements that callback, this means the supply_gregset etc. family of functions also needs a REGCACHE parameter. (This is probably a good idea anyway.) In short, the patch set changes the following arguments: extern void supply_gregset (struct regcache *regcache, const gdb_gregset_t *gregs); extern void supply_fpregset (struct regcache *regcache, const gdb_fpregset_t *fpregs); extern void fill_gregset (const struct regcache *regcache, gdb_gregset_t *gregs, int regno); extern void fill_fpregset (const struct regcache *regcache, gdb_fpregset_t *fpregs, int regno); extern void supply_fpxregset (struct regcache *regcache, const gdb_fpxregset_t *fpxregs); extern void fill_fpxregset (const struct regcache *regcache, gdb_fpxregset_t *fpxregs, int regno); void (*core_read_registers) (struct regcache *regcache, char *core_reg_sect, unsigned core_reg_size, int which, CORE_ADDR reg_addr); void (*to_fetch_registers) (struct regcache *, int); void (*to_store_registers) (struct regcache *, int); Note that I've attempted to make the supply_gregset etc. routines const-correct. This did expose two problems in current code: the m32r-linux-nat.c supply_gregset routine actually wrote into the register set it received, and the irix5-nat.c fill_ routines used regcache_raw_read (which may change the regcache) instead of regcache_raw_collect. The patch set fixes both issues. I've also tried to make the first argument to to_store_registers const, but that would cause difficulties for various targets: Several monitor targets use _read routines instead of _collect. That's probably just a bug. hppa-hpux and sparc use regcache_raw_read to read special register values ("flags" and sp, respectively) that are required to perform the store. It is not clear that this can be safely replaced by regcache_raw_collect; what if the register was not previously read? sol-thread.c deliberately saves/restores regcache contents for some reason ... i386gnu-nat.c actually deliberately supplies a new register value during to_store_registers in some cases. No idea what this is all about ... Since these issues are somewhat non-obvious to fix, I'd suggest to not bother making the argument const at this stage. The patch set implementing the above change consists of the following patches: Fix the const-correctness problems: 1. irix5-nat.c 2. m32r-linux-nat.c Prepare some (groups of) targets by pushing REGCACHE into internal helper routines: 3. aix-thread.c 4. alpha targets 5. arm targets 6. cris target 7. i387 targets 8. mips targets 9. sh targets 10. nto targets 11. monitor targets Convert supply_gregset etc. routines 12. (one patch) Convert core_fn core_read_registers callback 13. (one patch) Actually convert to_store_registers / to_fetch_registers 14. (one patch) Now, the testing issue :-) This patch set touches just about every single native target, and of course I cannot test even a significant fraction of those. I did full testing on: s390-ibm-linux s390x-ibm-linux i686-unknown-linux ia64-unknown-linux powerpc-ibm-aix5.3.0.0 powerpc64-unknown-linux spu-elf In addition, I've compiled every file touched by the patch set. Of course, this results in compiler errors due to missing native header files. However, I've made sure that after the patch set is applied, there is no *additional* error compared to before. As the patch set is pretty much mechanical, and shouldn't introduce any functional change at all, the fact that there are no further compiler errors should be a pretty good indication that it'll work ... I'd appreciate any feedback! Do you think this would be OK to commit? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com