From: "Eli Zaretskii" <eliz@elta.co.il>
To: Andrew Cagney <cagney@gnu.org>
Cc: cagney@gnu.org, gdb-patches@sources.redhat.com, kettenis@chello.nl
Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init
Date: Mon, 15 Mar 2004 19:55:00 -0000 [thread overview]
Message-ID: <9003-Mon15Mar2004215253+0200-eliz@elta.co.il> (raw)
In-Reply-To: <4055E603.3040904@gnu.org> (message from Andrew Cagney on Mon, 15 Mar 2004 12:21:07 -0500)
> Date: Mon, 15 Mar 2004 12:21:07 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> 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.
WARNING: multiple messages have this Message-ID
From: "Eli Zaretskii" <eliz@elta.co.il>
To: Andrew Cagney <cagney@gnu.org>
Cc: cagney@gnu.org, gdb-patches@sources.redhat.com, kettenis@chello.nl
Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <9003-Mon15Mar2004215253+0200-eliz@elta.co.il> (raw)
Message-ID: <20040319000900.4Ubi_E8HkjqGSGuqzq7O1FgkKMyjLuP6ZTfLQ_fBE_I@z> (raw)
In-Reply-To: <4055E603.3040904@gnu.org> (message from Andrew Cagney on Mon, 15 Mar 2004 12:21:07 -0500)
> Date: Mon, 15 Mar 2004 12:21:07 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> 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.
next prev parent reply other threads:[~2004-03-15 19:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-08 19:28 Andrew Cagney
2004-03-08 22:41 ` Mark Kettenis
2004-03-19 0:09 ` Mark Kettenis
2004-03-19 0:09 ` Andrew Cagney
2004-03-08 23:51 ` Andrew Cagney
2004-03-15 20:44 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-15 17:21 ` Andrew Cagney
2004-03-15 19:55 ` Eli Zaretskii [this message]
2004-03-15 21:13 ` Andrew Cagney
2004-03-17 11:30 ` Eli Zaretskii
2004-03-19 0:09 ` Eli Zaretskii
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-15 21:18 ` Andrew Cagney
2004-03-19 0:09 ` Eli Zaretskii
2004-03-19 0:09 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9003-Mon15Mar2004215253+0200-eliz@elta.co.il \
--to=eliz@elta.co.il \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox