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

Reply via email to