From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9679 invoked by alias); 8 Mar 2004 22:41:30 -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 9559 invoked from network); 8 Mar 2004 22:41:22 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 8 Mar 2004 22:41:22 -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 i28MfAwM000301; Mon, 8 Mar 2004 23:41:10 +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 i28MfA56000899; Mon, 8 Mar 2004 23:41:10 +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 i28MfAcH000896; Mon, 8 Mar 2004 23:41:10 +0100 (CET) Date: Mon, 08 Mar 2004 22:41:00 -0000 Message-Id: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com, eliz@is.elta.co.il In-reply-to: <404CC940.70805@gnu.org> (message from Andrew Cagney on Mon, 08 Mar 2004 14:28:00 -0500) Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init References: <404CC940.70805@gnu.org> X-SW-Source: 2004-03.o/txt/msg00178.txt Date: Mon, 08 Mar 2004 14:28:00 -0500 From: Andrew Cagney The dwarf2-frame code is then modified to use the first mechanism. I've left the other clients alone (but did deprecate set_gdbarch_data as that should now be redundant). I'm not so sure that set_gdbarch_data is now redundant. I can imagine that one would like to set a per-architecture data thingy to a different value after its initial initialization. So I'd rather you wouldn't deprecate the interface. Also note the name changes (better suggestions?). The names look fine to me. Mark From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9679 invoked by alias); 8 Mar 2004 22:41:30 -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 9559 invoked from network); 8 Mar 2004 22:41:22 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 8 Mar 2004 22:41:22 -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 i28MfAwM000301; Mon, 8 Mar 2004 23:41:10 +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 i28MfA56000899; Mon, 8 Mar 2004 23:41:10 +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 i28MfAcH000896; Mon, 8 Mar 2004 23:41:10 +0100 (CET) Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-ID: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com, eliz@is.elta.co.il In-reply-to: <404CC940.70805@gnu.org> (message from Andrew Cagney on Mon, 08 Mar 2004 14:28:00 -0500) Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init References: <404CC940.70805@gnu.org> X-SW-Source: 2004-03/txt/msg00178.txt.bz2 Message-ID: <20040319000900.d3t775egMWXMWLhu680mskY-0lUOp3OQQ_NcfJkWJ48@z> Date: Mon, 08 Mar 2004 14:28:00 -0500 From: Andrew Cagney The dwarf2-frame code is then modified to use the first mechanism. I've left the other clients alone (but did deprecate set_gdbarch_data as that should now be redundant). I'm not so sure that set_gdbarch_data is now redundant. I can imagine that one would like to set a per-architecture data thingy to a different value after its initial initialization. So I'd rather you wouldn't deprecate the interface. Also note the name changes (better suggestions?). The names look fine to me. Mark