From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24344 invoked by alias); 8 Mar 2004 23:51:01 -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 24309 invoked from network); 8 Mar 2004 23:51:00 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 8 Mar 2004 23:51:00 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C58E62B92; Mon, 8 Mar 2004 18:50:58 -0500 (EST) Message-ID: <404D06E2.2010805@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, eliz@is.elta.co.il Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init References: <404CC940.70805@gnu.org> <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> In-Reply-To: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00185.txt.bz2 > 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. Hmm, only one assignment has ever been possible: > set_gdbarch_data (struct gdbarch *gdbarch, > struct gdbarch_data *data, > void *pointer) > { > gdb_assert (data->index < gdbarch->nr_data); > gdb_assert (gdbarch->data[data->index] == NULL); > gdbarch->data[data->index] = pointer; > } and being able to do otherwize wasn't the intent. Instead of trying to modify the data thingie, code should modify the contents pointed to by the thingie. For instance, in dwarf2-frame: struct dwarf2_frame_ops { /* Pre-initialize the register state REG for register REGNUM. */ void (*init_reg) (struct gdbarch *, int, struct dwarf2_frame_state_reg *); }; the code can perform multiple assignments to "init_reg". > So I'd rather you > wouldn't deprecate the interface. > > Also note the name changes (better suggestions?). > > The names look fine to me. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24344 invoked by alias); 8 Mar 2004 23:51:01 -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 24309 invoked from network); 8 Mar 2004 23:51:00 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 8 Mar 2004 23:51:00 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C58E62B92; Mon, 8 Mar 2004 18:50:58 -0500 (EST) Message-ID: <404D06E2.2010805@gnu.org> Date: Mon, 08 Mar 2004 23:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, eliz@is.elta.co.il Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init References: <404CC940.70805@gnu.org> <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> In-Reply-To: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00185.txt Message-ID: <20040308235100.SQfIonag0QbbMmkDNxTTDNoqNiR7f9ezElJxaM-2q9c@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. Hmm, only one assignment has ever been possible: > set_gdbarch_data (struct gdbarch *gdbarch, > struct gdbarch_data *data, > void *pointer) > { > gdb_assert (data->index < gdbarch->nr_data); > gdb_assert (gdbarch->data[data->index] == NULL); > gdbarch->data[data->index] = pointer; > } and being able to do otherwize wasn't the intent. Instead of trying to modify the data thingie, code should modify the contents pointed to by the thingie. For instance, in dwarf2-frame: struct dwarf2_frame_ops { /* Pre-initialize the register state REG for register REGNUM. */ void (*init_reg) (struct gdbarch *, int, struct dwarf2_frame_state_reg *); }; the code can perform multiple assignments to "init_reg". > So I'd rather you > wouldn't deprecate the interface. > > Also note the name changes (better suggestions?). > > The names look fine to me. Andrew