From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29745 invoked by alias); 19 Nov 2003 21:45:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29722 invoked from network); 19 Nov 2003 21:45:12 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 19 Nov 2003 21:45:12 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hAJLj0nE000266; Wed, 19 Nov 2003 22:45:00 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hAJLj0ZH000340; Wed, 19 Nov 2003 22:45:00 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id hAJLixCZ000337; Wed, 19 Nov 2003 22:44:59 +0100 (CET) Date: Wed, 19 Nov 2003 21:45:00 -0000 Message-Id: <200311192144.hAJLixCZ000337@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com CC: gdb-patches@sources.redhat.com In-reply-to: <3FBBC696.9060102@redhat.com> (message from Andrew Cagney on Wed, 19 Nov 2003 14:37:58 -0500) Subject: Re: Pass gdbarch, not regset, to supply regset et.al.? References: <3FBBC696.9060102@redhat.com> X-SW-Source: 2003-11/txt/msg00408.txt.bz2 Date: Wed, 19 Nov 2003 14:37:58 -0500 From: Andrew Cagney Mark, I'm wondering if it would be easier to explicitly pass the gdbarch instead of the regset to the regset function? I've thought about that, but I don't think so. I'd like to use these register sets even for cases where there's no gdbarch that we can easily get at. I'm thinking specifically about the *-nat.c modules where register sets are provided by ptrace(2), /proc, etc. At present the lookup regset code does this: tdep->gregset = XMALLOC (struct regset); tdep->gregset->descr = tdep; tdep->gregset->supply_regset = i386_supply_gregset; so that the architecture is tunneled through to the regset function. const struct gdbarch_tdep *tdep = regset->descr; ... for (i = 0; i < tdep->gregset_num_regs; i++) I'm wondering if it would be easier to just pass the architecture? Well, you can always pass gdbarch as the description. The point is that the current implementation makes it possible to pass in something that isn't related to a gdbarch at all. I also think it doesn't necessarily make sense to copy the i386 implementation. For SPARC I'm already thinking about a somewhat different implementation. At the same time, I'm wondering if i386_regset_from_core_section should be abstracted a little so that, like reggroups it was set up: set_regset_supply_core_section (arch, ".reg", size, i386_supply_regset); set_regset_supply_core_section (arch, ".reg2", i386_supply_fpregset); Hey, since when is GDB is written in C++ ;-). ... f = regset_supply_from_core_section (core_arch, ".name", length); f (core_arch, current_regcache, regnum, contents, length); ... or even the short cut ... regset_supply_core_section (core_arch, ".name", current_regcache, regnum, contents, length); Thoughts? Well, your set_regset_supply_core_section proposal makes it a bit awkward to override a particular core section defenition for a specific target. Suppose that I have a generic i386 implementation for say ".reg" sections which I want to override for GNU/Hurd? I just came across this bit of PPC64 GNU/Linux code > void > ppc_linux_supply_gregset (char *buf) > { > int regi; > struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); > > for (regi = 0; regi < 32; regi++) > supply_register (regi, buf + 4 * regi); (yes, that's a "4" not "8") and was studying the new mechanism. It might pay to study the other PPC and PPC64 OS'es to see whether they could share an implementation. Mark