2011/1/1 Joseph S. Myers <jos...@codesourcery.com>: > [...] I found > several possible problems with the configurations for *-kfreebsd-gnu, > *-knetbsd-gnu and *-kopensolaris-gnu.
Ok. Unless indicated otherwise, my answers below apply to *-kfreebsd-gnu, which is the only in these 3 systems that is actively maintained. For the other two I wouldn't worry about either guessing or leaving them as-is. If minor breakage happens it's unlikely to bother anyone. > * 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. It's not as intended. On amd64 we use /lib/ld.so.1 and /lib/ld-kfreebsd-x86-64.so.1. > * 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? I'm not familiar with PT_GNU_STACK. Does a working _dl_make_stack_executable() in glibc [1] indicate it's supported? [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685&view=markup > * 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. I'm sorry. It seems this would be my fault (I introduced this with the first kfreebsd-gnu port). > Do the FreeBSD and NetBSD kernels really use identical instructions? Definitely not. But it's strange we didn't notice, we've been using it for several years. > 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; The only thing I know for sure is that those 2 syscalls don't work. Is there any possibility that linux-unwind.h is useful for GNU/kFreeBSD in its current state? I don't understand this code, but what I can do is confirm that disabling linux-unwind.h doesn't cause any breakage. Then we could disable it untill/unless someone more clued than me ports it to kFreeBSD. Would this be ok? > * A minor point: TARGET_VERSION, referring to Linux, is not overridden > by these configurations. Perhaps a common (or a fallback) string mentioning GNU and/or glibc would fit. But where's this displayed anyway? -- Robert Millan
