RFC: target macro->hook migration idea

[Zack Weinberg]

DJ Delorie <dj@redhat.com> writes:

> IMHO changing the API is a separate issue.
>
> When I said "design the target structure" I meant organizing the hooks
> into reasonable categories, not changing the hooks themselves.

Okay.  I am happy with this plan, then.



"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> In general the argument types of the macros have not been defined (and
> this has caused format warning problems in the past).  For every new
> function, the correct argument types need to be worked out (and
> documented).

It is usually obvious, but yes, definitely needs documenting.

> The macros specified to goto a label outside the macro (a problem
> discussed in projects/beginner.html) need redefining.

I think DJ's suggestion of making the hooks for these be predicate
functions, and then replacing the macros with "if (predicate()) goto LABEL"
inline, is a good one.  The transitional wrapper routine can look like this:

bool
predicate(...)
{
  GO_IF_whatever(..., return_true);

  return false;
return_true:
  return true;
}

> Some methodology needs working out for what should be a macro and
> what should be a function.  I presume that e.g. the basic macros for
> type sizes (that generally expand to integer constants) aren't
> intended to move to the structure.

Whereas I presume that they _are_; consider that a goal here is to be
able, at least in principle, to swap out the back end at runtime.

> The mess of default macro definitions not all being in defaults.h
> needs sorting out, if the default function definitions are to go in
> one place.

This is a problem, but can probably be resolved by a single sweep to
find all the default definitions that aren't in defaults.h and move
them there.

> The mess of target macros being used in definitions of other target
> macros (where replacement by a call to the function may not always
> be appropriate) needs sorting out.

This should be doable incrementally.

> Default (or other) definitions of a macro duplicated in many targets
> need sorting out (with a per-port conversion this duplication is
> less visible than with a per-macro conversion), and the definitions
> in common files such as elfos.h probably need to be converted to
> single central functions, documented as available for ports wanting
> a particular behaviour.

For any given hook, if all the ports have individually been converted
to proper hook implementations, duplication among the hooks should be
much easier to observe and factor out than duplication among all the
original macros would have been.

I imagine that the typical process will now be a series of per-port
patches for any given macro (or set of macros, if it is obvious that
some collapsing is in order) followed by a global cleanup.

zw