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