Re: [PATCH 4/4] Introduce class target_stack

[Tom Tromey <tom at tromey dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> The problem then is in finding a target's "beneath" target, if we
Pedro> consider that for some target_ops types, we'll be sharing a
Pedro> single target_ops instance between several inferiors.  For
Pedro> example, so far, I found no need to have multiple instances of
Pedro> the spu_multiarch_target / exec_target / dummy_target targets.

Is it the case that sometimes a particular target_ops instance will have
to be shared among multiple target stacks?

If so, then this all makes sense to me.

If not, then it seems maybe slightly off, because then if you need to
add state to some existing target_ops, you will have to check whether it
is shareable and then ensure it is unshared -- does this make sense?
But on the other hand, an instance of something like dummy_target should
be cheap (sizeof == 24 here).  So maybe a simpler rule is available.

On the third hand, it's only slightly off, and I don't want to get in
the way of this important project; but I would still like to understand.

Pedro> +/* The target stack.  */
Pedro> +static target_stack g_target_stack;

As an aside, I often wonder about blank lines between comments and
definitions.

I prefer not to have them, though not for any actual reason.  But some
spots have them and some do not, so in practice what I do is either
follow the local style; or leave the blank line out if I think I can; or
else feel guilty since I vaguely recall there was a rule to have one and
so put it in even though I'd rather not.

Pedro> +   Note that rather than allow an empty stack, we always have the
Pedro> +   dummy target at the bottom stratum, so we can call the function
Pedro> +   vectors without checking them.  */

Probably just "methods" rather than "function vectors".

Tom