From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12387 invoked by alias); 21 Nov 2003 18:39:04 -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 12360 invoked from network); 21 Nov 2003 18:39:03 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 21 Nov 2003 18:39:03 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 42A302B8F; Fri, 21 Nov 2003 13:39:00 -0500 (EST) Message-ID: <3FBE5BC4.4010409@redhat.com> Date: Fri, 21 Nov 2003 18:39: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: 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> <3FBBFC9D.9080300@gnu.org> <200311211531.hALFV27t000341@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00440.txt.bz2 > * It's a bit of a hassle to get at the right architecture from within > a *-nat.c module. (it's a bit of a hassle more generally too :-) target->lwp->architecture? > * There are cases where there are several implied architectures to > choose from. > * What's the implied architecture of an architecture-independent > remote protocol? I'd like to make these register sets work for > remote protocols too, without havong to associate some sort og > "generic" gdbarch with it. > > 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? > > There might be too much generality, but that's certainly better than > too little generality. I've defenitely got the feeling that gdbarch > gives us too little generality. (Think yourself lucky. At one stage people were arguing that the architecture and target vector should be combined into a single monolythic mess :-(). "regsets" could be made more independant of gdbarch by having its own local table and search methods: add_corefile_regset (bfd_arch, mach, size, name, ..., method); corefile_regset (bfd_arch, mach, name, size) and a wrapper: gdbarch_corefile_regset (gdbarch, name, size) -> corefile_regset (gdbarch->bfd_arch, name, size) Anyway, how were you thinking of doing things for the sparc? Andrew