This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: kfreebsd-gnu etc. issues
2011/1/1 Joseph S. Myers <joseph@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