This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

handling of config #defines

In the process of streamlining the configuration info for various
VxWorks and VxWorks AE targets we are running into an ordering
problem.  For example, for rs6000 we would like to use a single
target-configuration file, config/rs6000/vxppc.h.  Then, in, we cause either config/vxworks.h or config/vxworksae.h
to be prepended to tm_h depending on the OS in the target triple.
These OS-specific .h files #define, among other things, OS-specific
macros that can be used, if necessary, in the target-specific files.

This approach fails for power-pc and certain other targets.  For
example, vxppc.h was designed long ago on the assumption that it was
to be like Sys V.4, only "just a little different."  So, at the very
top it #includes rs6000/sysv4.h, which in turn #includes
rs6000/rs6000.h.  All this makes sense because the Embedded ABI for
Power PC is based mainly on the Sys V.4 ABI.  Unfortunately (for
example) vxworks.h (but not vxworksae.h) needs to #undef
ASM_WEAKEN_SYMBOL, a macro which then then gets re-#define'd in
rs6000/sysv4.h.  This is just the tip of a small iceberg.

So, my question is this: what is the most "cleanly" way of dealing
with this problem?  One uncleanly way would be to conditionally simply
re-#define ASM_WEAKEN_SYMBOL in vxppc.h.  Doing so, however defeats
the goal of encapsulating the OS-dependent info in the OS-specific

A more cleanly way, IMHO, would be to modifiy rs6000/vxppc.h so that
ASM_WEAKEN_SYMBOL, and certain other macro #define's, are wrapped in

Jim Dein

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]