From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13060 invoked by alias); 19 Nov 2003 23:28:50 -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 13020 invoked from network); 19 Nov 2003 23:28:44 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 19 Nov 2003 23:28:44 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E5BD12B8F; Wed, 19 Nov 2003 18:28:29 -0500 (EST) Message-ID: <3FBBFC9D.9080300@gnu.org> Date: Wed, 19 Nov 2003 23:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: Pass gdbarch, not regset, to supply regset et.al.? References: <3FBBC696.9060102@redhat.com> <200311192144.hAJLixCZ000337@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00410.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. Sorry, I'm lost. ptrace and /proc both have an implied architecture, or at least OS. > 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. Will anyone every actually do this, or have we ended up with too much generality? > 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++ ;-). shhhh > ... > 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? set_regset_core_section (arch, ".reg", size, i386_collect_gregset) ... then later ... set_regset_core_section (arch, ".reg", size, gnuhurd_collect_gregset)? > 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. True. Andrew