I'm trying to stop non-Linux GCC targets from using config/linux.h and other headers whose names indicate they relate to the Linux kernel, separating GNU-userspace and Linux-kernel configuration more cleanly. <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html> is the initial patch in this series, and in the course of working on the corresponding changes for i386/linux.h and i386/linux64.h I found several possible problems with the configurations for *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu.
* The headers config/kfreebsd-gnu.h etc. override GLIBC_DYNAMIC_LINKER. But the 64-bit configurations x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to use any header that would override GLIBC_DYNAMIC_LINKER32 and GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h actually uses. Thus those configurations would use Linux-specific dynamic linker settings, which seems unlikely to be as intended. * These configurations use file_end_indicate_exec_stack to use the PT_GNU_STACK convention. While some of the implementation of this is in the GNU linker and glibc, it also requires kernel support for correct operation. Do all these kernels support this convention, or should this code actually be disabled for them in GCC and glibc? * The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h (kopensolaris-gnu disables this). They define REG_NAME to adapt linux-unwind.h to their system headers. But linux-unwind.h also contains hardcoded checks for the particular instructions, complete with hardcoded Linux syscall numbers, in Linux signal trampolines. Do the FreeBSD and NetBSD kernels really use identical instructions? Does this code do anything useful on those systems? If it's useful (possibly with some fixes) then linux-unwind.h ought to be renamed; otherwise those configurations should not be using it. * A minor point: TARGET_VERSION, referring to Linux, is not overridden by these configurations. If these issues can be fixed by someone who knows what is correct for those targets then it would help with this cleanup - and while such rearrangements of headers used on GNU/Linux may best be avoided in development Stage 4, it should be fine to make changes then that are only relevant to kfreebsd-gnu, knetbsd-gnu and kopensolaris-gnu. -- Joseph S. Myers jos...@codesourcery.com