From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27020 invoked by alias); 21 Nov 2003 15:31:24 -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 26996 invoked from network); 21 Nov 2003 15:31:21 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 21 Nov 2003 15:31:21 -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 hALFV3NK000277; Fri, 21 Nov 2003 16:31:03 +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 hALFV3a5000344; Fri, 21 Nov 2003 16:31:03 +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 hALFV27t000341; Fri, 21 Nov 2003 16:31:02 +0100 (CET) Date: Fri, 21 Nov 2003 15:31:00 -0000 Message-Id: <200311211531.hALFV27t000341@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: ac131313@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <3FBBFC9D.9080300@gnu.org> (message from Andrew Cagney on Wed, 19 Nov 2003 18:28:29 -0500) 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> X-SW-Source: 2003-11/txt/msg00436.txt.bz2 Date: Wed, 19 Nov 2003 18:28:29 -0500 From: Andrew Cagney > 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. Yes they do, but: * It's a bit of a hassle to get at the right architecture from within a *-nat.c module. * 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. Mark