From: Andrew Cagney <cagney@gnu.org>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com, eliz@is.elta.co.il
Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <404D06E2.2010805@gnu.org> (raw)
In-Reply-To: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org>
> Date: Mon, 08 Mar 2004 14:28:00 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> 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
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <cagney@gnu.org>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com, eliz@is.elta.co.il
Subject: Re: [patch/rfc] Separate gdbarch_data_register_pre_init
Date: Mon, 08 Mar 2004 23:51:00 -0000 [thread overview]
Message-ID: <404D06E2.2010805@gnu.org> (raw)
Message-ID: <20040308235100.SQfIonag0QbbMmkDNxTTDNoqNiR7f9ezElJxaM-2q9c@z> (raw)
In-Reply-To: <200403082241.i28MfAcH000896@elgar.kettenis.dyndns.org>
> Date: Mon, 08 Mar 2004 14:28:00 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> 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
next prev parent reply other threads:[~2004-03-08 23:51 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 [this message]
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
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-15 21:18 ` Andrew Cagney
2004-03-19 0:09 ` 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=404D06E2.2010805@gnu.org \
--to=cagney@gnu.org \
--cc=eliz@is.elta.co.il \
--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