On Mon, Jun 21, 2004 at 09:12:25AM +0200, Emmanuel Dreyfus wrote:
> Paul Kranenburg <pk@cs.few.eur.nl> wrote:
> 
> > > On the other hand, if we don't do anything, we
> > > will have a lot of regression in binary compatibility options...
> > 
> > Including our own NetBSD 1.x a.out compatibility (on some archs)..
> > 
> > I ran into this a few weeks ago on sun4m/sparc but haven't had much time
> > to investigate. It looks though that the cause is a non-executable
> > map of ld_aout.so's procedure jump table.
> 
> If non executable mappings are alwways enabled, doesn't that mean that
> we break signal delivery in binaries from NetBSD 1.6? If that's the
> case, it's a very bad point.

signal delivery should work fine to all binaries.  in prior releases,
the kernel would copy a signal trampoline to the stack and execute it
from there, but one of the changes I made at the same time as mapping
the stack non-executable was to arrange for the signal trampoline
to be mapped separately from the stack.  see exec_sigcode_map().

just now I double-checked with a netbsd 1.6.2 binary running under
a post-2.0 kernel (on powerpc), and it could catch and return from
signals just fine.

-Chuck