On Wed, 16 Jul 2014, Peter Bergner wrote: > > > This seems weird. Why wasn't this file included before or whenever it > > > was added for other *-linux targets? This seems to define SPECs that > > > should have been necessary before now. > > This was comitted by Joseph with revision 168711 and submitted here: > > https://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html > > The patch seems to move some defines from linux.h to gnu-user.h and > it looks like powerpc*-linux doesn't include linux.h either. > Is that another header file we're supposed to include? ...or do > our rs6000/linux{,64}.h header files completely obviate the need > for that?
I believe the historical reason for not including the architecture-independent headers was the -mcall-* handling in rs6000/sysv4.h to allow a compiler for one target to build / link as if for another target for that architecture. That arrangement means all the main specs are defined via per-OS named specs, with rs6000/sysv4.h containing the definitions of the underlying specs for each OS. When specs come from the architecture-independent linux.h or gnu-user.h, other OS compilers with -mcall-linux will not get those specs and so will not properly link in the way a compiler configured for GNU/Linux target will. Enough configuration is in fact done in the OS-specific headers that I don't think the -mcall-* handling of specs is useful any more (or has been for a long time). (The compile-time handling of -mcall-* to select a particular ABI in SUBTARGET_OVERRIDE_OPTIONS may be more useful and seems unproblematic.) So as I said in the message you refer to (and elsewhere), I think it would be a useful cleanup (and would not remove any feature that is actually usable) to remove the -mcall-* specs handling and make powerpc* targets more like other architectures in this regard - each OS's headers define the specs for that OS without the added indirection. (I'm doubtful of the current use of -mads -myellowknife -mmvme as well - other architectures avoid having such special compiler options for each BSP.) -- Joseph S. Myers jos...@codesourcery.com
