From: Daniel Jacobowitz <drow@mvista.com>
To: Jim Ingham <jingham@apple.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: add set cp-abi command
Date: Fri, 15 Mar 2002 19:41:00 -0000 [thread overview]
Message-ID: <20020315224121.B3612@nevyn.them.org> (raw)
In-Reply-To: <C077653E-386F-11D6-8354-000393540DDC@apple.com>
On Fri, Mar 15, 2002 at 03:52:47PM -0800, Jim Ingham wrote:
> Daniel,
>
> Okay, how about this.
>
> I changed the set/show as per set language.
>
> I added an "auto" abi. This ended up being a little tricky because I
> don't know the order in which the initializers get run, but this works.
>
> In the process of doing this I got really annoyed that EVERYTHING was
> done by copying structures around. If we think that it is really
> important to have the current_cp_abi be a structure rather than a
> pointer to a structure so there was one less level of indirection,
> that's fine. But there is no reason to manage the internal list this
> way as well. So I changed cp_abis to be an array of pointers to
> cp_abi_ops structures, and had to change the auto-grow mechanism to
> account for it.
>
> I also took out the extern def'ns of num_cp_abis, cp_abis and
> current_cp_abi out of cp-abi.h. They weren't currently used outside the
> module, and if we end up needing to use them, we should provide
> interfaces, rather than just poking around at the data.
>
> I haven't written a doc note for this, I have run out of time for this
> today, but thought I would give you a look before the day is out...
Better. I have a couple of nits, but mostly I like it. You've
probably thought of some of these; I realize it's a WIP.
I don't think you had to do anything nearly as complicated to the array
growth code, for one thing. You could have simply grown it by sizeof
(struct cp_abi_ops *) instead of sizeof (struct cp_abi_ops) as it was
before.
> ! static struct cp_abi_ops current_cp_abi;
As in your other message... we can not assume anything about
initializer order. This periodically makes me cry.
> ! static struct cp_abi_ops auto_cp_abi = {"auto", NULL};
>
> ! #define INITIAL_CP_ABI_MAX 8
>
> ! static struct cp_abi_ops *orig_cp_abis[INITIAL_CP_ABI_MAX];
> ! static struct cp_abi_ops **cp_abis = orig_cp_abis;
> ! static int max_cp_abis = INITIAL_CP_ABI_MAX;
> int
> ! register_cp_abi (struct cp_abi_ops *abi)
> ! {
> ! if (num_cp_abis == max_cp_abis)
> {
> ! struct cp_abi_ops **new_abi_list;
> ! int i;
> !
> ! max_cp_abis *= 2;
> ! new_abi_list = (struct cp_abi_ops **) xmalloc (max_cp_abis *
> sizeof (struct cp_abi_ops *));
> ! for (i = 0; i < num_cp_abis; i++)
> ! new_abi_list[i] = cp_abis[i];
> !
> ! if (cp_abis != orig_cp_abis)
> ! xfree (cp_abis);
> !
> ! cp_abis = new_abi_list;
> ! }
> !
> cp_abis[num_cp_abis++] = abi;
>
> return 1;
>
> }
No point in having all this complexity. We could dynamically allocate
the array in the first place, or even use a linked list if that were
simpler. I think an array of just pointers, managed the same way the
old array was, is fine. A couple extra xreallocs are worth the
simplicity.
> + void
> + set_cp_abi_as_auto_default (struct cp_abi_ops *abi)
> + {
> +
> + if (auto_cp_abi.longname != NULL)
> + xfree (auto_cp_abi.longname);
Crash the first time you set an ABI, I think - auto_cp_abi.longname
points to "auto" in your rodata. Did this survive on Darwin?
> + auto_cp_abi.longname = (char *) xmalloc (11 + strlen
> (abi->shortname));
11? Oh, I see, "currently \0". Please use a sizeof("blah") for this
sort of thing; magic numbers are bad.
> + auto_cp_abi.is_destructor_name = abi->is_destructor_name;
> + auto_cp_abi.is_constructor_name = abi->is_constructor_name;
> + auto_cp_abi.is_vtable_name = abi->is_vtable_name;
> + auto_cp_abi.is_operator_name = abi->is_operator_name;
> + auto_cp_abi.virtual_fn_field = abi->virtual_fn_field;
> + auto_cp_abi.rtti_type = abi->rtti_type;
> + auto_cp_abi.baseclass_offset = abi->baseclass_offset;
> +
> + /* Since we copy the current ABI into current_cp_abi instead of using
> + a pointer, if auto is currently the default, we need to reset
> it. */
Is there some way we could manage all this with pointers instead? I
don't like having to copy this structure above. It's just another bug
every time I add an ABI-specific method, of which I suspect I'll need a
few more.
> ! char *longname; /* These two can't be const, because I need to */
> ! char *doc; /* change the name for the auto abi. */
Then perhaps the name of the currently selected auto ABI should be
stored somewhere else... that should be simpler.
> const char *name = SYMBOL_NAME (&objfile->msymbols[i]);
> if (name[0] == '_' && name[1] == 'Z')
> {
> + if (cp_abi_is_auto_p ())
> switch_to_cp_abi ("gnu-v3");
> break;
> }
This bit, of course, is great :)
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-03-16 3:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 10:56 Jim Ingham
2002-03-13 12:11 ` Eli Zaretskii
2002-03-13 12:11 ` Daniel Jacobowitz
2002-03-14 13:14 ` Jim Ingham
2002-03-14 13:26 ` Daniel Jacobowitz
2002-03-15 15:53 ` Jim Ingham
2002-03-15 19:41 ` Daniel Jacobowitz [this message]
2002-03-18 12:01 ` Jim Ingham
2002-03-20 15:19 ` Daniel Jacobowitz
2002-03-20 19:02 ` Jim Ingham
2002-03-22 10:34 ` Daniel Jacobowitz
2002-03-22 11:04 ` Andrew Cagney
2002-03-22 11:09 ` Daniel Jacobowitz
2002-03-22 11:29 ` Jim Ingham
2002-04-09 17:27 ` Jim Ingham
2002-04-09 17:54 ` Daniel Jacobowitz
2002-04-10 11:10 ` Jim Ingham
2002-04-10 11:58 ` Daniel Jacobowitz
2002-04-09 22:33 ` Eli Zaretskii
2002-04-10 11:14 ` Jim Ingham
2002-04-11 12:25 ` Eli Zaretskii
2002-03-15 17:11 ` Jim Ingham
2002-03-14 15:29 ` Andrew Cagney
2002-03-15 10:33 ` Jim Ingham
2002-03-15 17:29 ` 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=20020315224121.B3612@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jingham@apple.com \
/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