Re: kfreebsd-gnu etc. issues
2011/1/12 Robert Millan r...@gnu.org: * 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. It seems x86_64-kfreebsd-gnu has been broken for a while. I just realized that I wrote a patch to fix this in 2006 [1], but somehow it was never merged in GCC (actually I'm not even sure I submitted it). In the meantime Debian GNU/kFreeBSD has been using this patch to build GCC on their kfreebsd-amd64 port. I can prepare an updated version of this patch (relative to trunk + your linux.h overhaul [2]). [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/web/patches/upstream-only/gcc.diff?view=markuppathrev=1424 [2] http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html -- Robert Millan
Re: kfreebsd-gnu etc. issues
2011/1/12 Ian Lance Taylor i...@google.com: All that said, I see little harm in using a PT_GNU_STACK header on binaries even if the kernel does not fully support them. Except for the small amount of wasted space in every .o file and every executable, but I lost that argument years ago. Thanks Ian. Seeing that there's so little harm in enabling it gratuitously, I think it'd be best to assume that PT_GNU_STACK is supported unless someone can prove otherwise. -- Robert Millan
Re: kfreebsd-gnu etc. issues
On Fri, 14 Jan 2011, Robert Millan wrote: I can prepare an updated version of this patch (relative to trunk + your linux.h overhaul [2]). Yes, that seems appropriate (it would now just be relevant to trunk since my gnu-user.h patch is now in trunk). -- Joseph S. Myers jos...@codesourcery.com
Re: kfreebsd-gnu etc. issues
2011/1/12 Joseph S. Myers jos...@codesourcery.com: 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? That makes sense to me. Confirmed, linux-unwind.h can be removed. If disabled for non-Linux-kernel targets, the REG_NAME abstraction may as well be removed as not actually being useful at present. Ack. I'll send a patch for this. -- Robert Millan
Re: kfreebsd-gnu etc. issues
On Wed, 12 Jan 2011, Robert Millan wrote: Hi Joseph I'll look at more detail at the other problems, but first it seems that non-Linux GNU targets are currently broken because many declarations that are not Linux-specific have been added to the Linux-specific sections of config.gcc. I don't think they are necessarily broken - and if they are, it is because of Linux-specific headers being used in non-Linux-specific code, not the other way round. Should I wait untill your patch is merged to fix this? No. Btw, your patch overhauls linux.h but not i386/linux64.h which is in the same situation as you described. Indeed. While the subdirectory */*linux*.h headers that are used by non-Linux-kernel targets need splitting up, and removing from the headers used by non-Linux-kernel targets, separating this from splitting up the architecture-independent header leads to smaller patches such that it is easier for the author and patch reviewer to convince themselves that there are no unintended changes to semantics. Furthermore, it was while looking at splitting up the i386/*.h headers that I found the issues raised in my message you're replying to. And two of those four issues are issues where I am seeking information from someone familiar with the *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu targets in order to determine which definitions actually belong in Linux-kernel headers and which in GNU-userspace headers. So if you could clarify the answers to my questions regarding PT_GNU_STACK and signal frames for those targets (with or without fixing any bugs for those targets indicated by the answers to those questions), that would help determine the correct division of those headers. In turn, actually stopping non-Linux-kernel targets from using config/linux.h depends on splitting up the subdirectory linux.h files, because of how those interact with config/linux.h. -- Joseph S. Myers jos...@codesourcery.com
Re: kfreebsd-gnu etc. issues
2011/1/12 Joseph S. Myers jos...@codesourcery.com: I don't think they are necessarily broken - and if they are, it is because of Linux-specific headers being used in non-Linux-specific code, not the other way round. Actually, it's a different problem. I'll just prepare a patch and send it, it'll be obvious by reading the patch. So if you could clarify the answers to my questions regarding PT_GNU_STACK and signal frames for those targets (with or without fixing any bugs for those targets indicated by the answers to those questions), that would help determine the correct division of those headers. Ok, I'll answer what I can in your previous mail. -- Robert Millan
Re: kfreebsd-gnu etc. issues
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=1685view=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
Re: kfreebsd-gnu etc. issues
On Wed, 12 Jan 2011, Robert Millan wrote: * 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? I think the glibc code is necessary but may not be sufficient; whatever kernel support there is or isn't, glibc needs to know how the kernel will have set things up (on Linux, based on PT_GNU_STACK for the dynamic linker, I think) in order to adjust it based on the PT_GNU_STACK of the executable and shared libraries. Probably it's possible to get this right without kernel support (if glibc does the right things at startup), in which case we could consider this a GNU userspace convention. 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 see how it can be useful in its current state for any system using different syscall numbers. Maybe the code using a ucontext would be relevant given code checking for different (kernel-dependent) instructions. 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? That makes sense to me. If disabled for non-Linux-kernel targets, the REG_NAME abstraction may as well be removed as not actually being useful at present. * 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? In collect2 (only, for these targets; mips-tdump and mips-tfile also use it). I've also suggested that we should eliminate TARGET_VERSION completely (probably for 4.7) but while it's there, referring to Linux for these targets is wrong. -- Joseph S. Myers jos...@codesourcery.com
Re: kfreebsd-gnu etc. issues
Robert Millan r...@gnu.org writes: 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=1685view=markup PT_GNU_STACK is a program header recognized by the Linux kernel when loading an ELF executable or shared library. If any executable or shared library has a PT_GNU_STACK segment for which the PF_X bit is set in the p_flags field, then the kernel will mark the stack as permitting execution (i.e., will mmap it with PROT_EXEC as well as PROT_READ and PROT_WRITE). _dl_make_stack_executable is a related but distinct mechanism which is used by the dynamic linker to make the stack executable when 1) the stack was loaded as non-executable; 2) there is now some reason to make the stack executable, e.g., a dlopen of a shared library which has a PT_GNU_STACK header indicating that an executable stack is required. As Joseph said, for the specific (and common) case of dynamically linked binaries it's possible to make this work without kernel support, under the assumption that the kernel runs the dynamic linker without an executable stack. However, for statically linked binaries, PT_GNU_STACK is only useful if the kernel supports it. All that said, I see little harm in using a PT_GNU_STACK header on binaries even if the kernel does not fully support them. Except for the small amount of wasted space in every .o file and every executable, but I lost that argument years ago. Ian
Re: kfreebsd-gnu etc. issues
Hi Joseph I'll look at more detail at the other problems, but first it seems that non-Linux GNU targets are currently broken because many declarations that are not Linux-specific have been added to the Linux-specific sections of config.gcc. Should I wait untill your patch is merged to fix this? Btw, your patch overhauls linux.h but not i386/linux64.h which is in the same situation as you described. -- Robert Millan
Re: kfreebsd-gnu etc. issues
Hi Joseph, 2011/1/1 Joseph S. Myers jos...@codesourcery.com: 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 Thank you for doing this. As the person who introduced this kind of use, I intended to propose something along these lines myself, but never got the time to do it. I found several possible problems with the configurations for *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu. [...] I can't review these problems right now, but I'll have a bit more time in 1 or 2 weeks. I'll get back to you. -- Robert Millan
kfreebsd-gnu etc. issues
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