From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21055 invoked by alias); 15 Mar 2004 19:55:11 -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 21043 invoked from network); 15 Mar 2004 19:55:10 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sources.redhat.com with SMTP; 15 Mar 2004 19:55:10 -0000 Received: from zaretski ([80.230.157.53]) by aragorn.inter.net.il (MOS 3.4.4-GR) with ESMTP id CPJ58471; Mon, 15 Mar 2004 21:54:38 +0200 (IST) Date: Mon, 15 Mar 2004 19:55:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-Id: <9003-Mon15Mar2004215253+0200-eliz@elta.co.il> CC: cagney@gnu.org, gdb-patches@sources.redhat.com, kettenis@chello.nl In-reply-to: <4055E603.3040904@gnu.org> (message from Andrew Cagney on Mon, 15 Mar 2004 12:21:07 -0500) Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init Reply-to: Eli Zaretskii References: <404CC940.70805@gnu.org> <4055E603.3040904@gnu.org> X-SW-Source: 2004-03.o/txt/msg00325.txt > Date: Mon, 15 Mar 2004 12:21:07 -0500 > From: Andrew Cagney > > How does the doco part of this change look? Looks okay to me, except for the following small gotchas: > ! @var{post_init} is used to obtain an initial value for a > ! per-architecture data-pointer @emph{after}. Since @var{post_init} is > ! always called after architecture creation, it both receives the fully > ! initialized architecture and is free to call modules that use > ! per-architecture data (care should be taken to avoid cycles in the > ! call graph). > ! @end deftypefun This sounds like important notes, but they are worded too vaguely, IMHO. A question that popped up in my mind when I read that was: what cycles should I avoid in the call graph, and how? Perhaps an example would help drive these points home. > ! current value of the per-architecture data-pointer. If the data > ! pointer is @code{NULL}, it is first initialize by calling the ^^^^^^^^^^^^^^^^^^^^^^ A typo: it should be "initialized". > ! The examples below assuming the following definitions: ^^^^^^^^ "The examples ... assume ..." > ! A module can extend the architecture vector, adding additional > ! per-architecture attributes, using the @var{pre_init} method. These > ! attribute being set by the architecture's @var{gdbarch_init} method > ! during architecture creation. "These attributes are set by the architecture's @var{gdbarch_init} method ...". Btw, what ``attributes'' are those? The text doesn't explain that. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21055 invoked by alias); 15 Mar 2004 19:55:11 -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 21043 invoked from network); 15 Mar 2004 19:55:10 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sources.redhat.com with SMTP; 15 Mar 2004 19:55:10 -0000 Received: from zaretski ([80.230.157.53]) by aragorn.inter.net.il (MOS 3.4.4-GR) with ESMTP id CPJ58471; Mon, 15 Mar 2004 21:54:38 +0200 (IST) Date: Fri, 19 Mar 2004 00:09:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <9003-Mon15Mar2004215253+0200-eliz@elta.co.il> CC: cagney@gnu.org, gdb-patches@sources.redhat.com, kettenis@chello.nl In-reply-to: <4055E603.3040904@gnu.org> (message from Andrew Cagney on Mon, 15 Mar 2004 12:21:07 -0500) Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init Reply-to: Eli Zaretskii References: <404CC940.70805@gnu.org> <4055E603.3040904@gnu.org> X-SW-Source: 2004-03/txt/msg00325.txt.bz2 Message-ID: <20040319000900.4Ubi_E8HkjqGSGuqzq7O1FgkKMyjLuP6ZTfLQ_fBE_I@z> > Date: Mon, 15 Mar 2004 12:21:07 -0500 > From: Andrew Cagney > > How does the doco part of this change look? Looks okay to me, except for the following small gotchas: > ! @var{post_init} is used to obtain an initial value for a > ! per-architecture data-pointer @emph{after}. Since @var{post_init} is > ! always called after architecture creation, it both receives the fully > ! initialized architecture and is free to call modules that use > ! per-architecture data (care should be taken to avoid cycles in the > ! call graph). > ! @end deftypefun This sounds like important notes, but they are worded too vaguely, IMHO. A question that popped up in my mind when I read that was: what cycles should I avoid in the call graph, and how? Perhaps an example would help drive these points home. > ! current value of the per-architecture data-pointer. If the data > ! pointer is @code{NULL}, it is first initialize by calling the ^^^^^^^^^^^^^^^^^^^^^^ A typo: it should be "initialized". > ! The examples below assuming the following definitions: ^^^^^^^^ "The examples ... assume ..." > ! A module can extend the architecture vector, adding additional > ! per-architecture attributes, using the @var{pre_init} method. These > ! attribute being set by the architecture's @var{gdbarch_init} method > ! during architecture creation. "These attributes are set by the architecture's @var{gdbarch_init} method ...". Btw, what ``attributes'' are those? The text doesn't explain that.