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

Reply via email to