Sandra Loosemore schrieb:
The internals manual says that a backend for $target should have
$target.h and $target-protos.h files, but doesn't say what the
difference between them is or what belongs in which file. Current
practice seems to be a mix of
(1) $target.h contains macro definitions and $target-protos.h contains
extern declarations.
(2) $target.h defines the external interface to the backend (the macros
documented in the internals manual) and $target-protos.h contains things
shared between $target.c and the various .md files.
But some generic source files include $target.h only and some source
files include both, which wouldn't be true if either of the above models
applied. So is there some other logical way to explain the difference
and what goes where?
IIRC, one difference is scanning for GTY markers used to tag ggc roots:
$target.h is scanned whereas $target-protos.h is not (and AFAIR adding
$target-protos.h in config.gcc to the files being scanned pops up other
problems). Hence when you have a target-specific GTYed structure that's
shared by several back-end modules, you'd add the struct definition to
$target.h (If only one module needs such objects, then you'd add the
type definition to, say, $target.c which is scanned — or can be rendered
to a scanned one by adjusting config.gcc).
The bulk of code is not GTYed, of course, and from my experience the
usage of the mentioned files is like you summarized: $target-protos.h is
usually a blob of prototypes used internally to communicate within a
back-end, whereas $target.h "defines" the backend part that's not yet
hookized, e.g. the TARGET_ macros that define (initializers for)
register classes etc.
And the usage in libgcc might be different: $target.h is used in libgcc
(which is the reason for why $target.h might need runtime library
exceptions, cf. PR61152:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152#c0 ) Ideally, all
information needed by libgcc and other target libraries would be shipped
by built-in macros, but such complete separation from compiler sources
from libgcc sources is not yet complete to the best of my knowledge.
$target-protos.h (via tm_p.h), however, is not used by libgcc.
Johann
The thing that got me thinking about this is looking at a new port
originally written by a customer, where it seems like there is too much
stuff in $target.h. Then I started chasing it down....
- FUNCTION_BOUNDARY depends on which arch variant is being compiled for
- Its expansion references some internal target data structures and
enumerators to look up that info
- The default definition of TARGET_PTRMEMFUNC_VBIT_LOCATION uses
FUNCTION_BOUNDARY
- ipa-prop.c uses TARGET_PTRMEMFUNC_VBIT_LOCATION but doesn't include
$target-protos.h
- tree.c also uses FUNCTION_BOUNDARY directly without including
$target-protos.h
- Probably there are many other target macros that potentially have
similar issues
- Presumably this means everything referenced in the expansion of any
target macro in $target.h also needs to be declared in $target.h and not
depend on $target-protos.h also being included at the point of use.
So what is the purpose of having a separate $target-protos.h?
-Sandra the confused
