hi,

running the test with the patch does produce SIGSEGV/SEGV_ACCERR,
but the test hangs.  here's a ktrace:

   691 sh       0.002990 RET   __vfork14 735/0x2df
   691 sh       0.000192 CALL  getpgrp
   691 sh       0.000136 RET   getpgrp 562/0x232, 20/0x14
   691 sh       0.000155 CALL  wait4(0xffffffffffffffff,0xffffffffffffcf2c,0,0)
   735 tramptest 0.002127 CALL  __sigaction_sigtramp(0xb,0xffffffffffffd5f0,0,0x404bc1a8,0x1)
   735 tramptest 0.000162 RET   __sigaction_sigtramp 0, -10768/0xffffffffffffd5f0
   735 tramptest 0.000158 PSIG  SIGSEGV caught handler=0x100bf0 mask=(): code=SEGV_ACCERR, addr=0xffffffffffffd5c0, trap=100)
   562 make     19.297951 PSIG  SIGINT caught handler=0x103c54 mask=())
...
   735 tramptest 0.000642 PSIG  SIGINT SIG_DFL



when I hit ^C after 15 seconds or so, it takes a few seconds for it to be
received on the other side.  it's entering uvm_fault() again and again,
apparently get a data fault on address 0:

1077373385.515868 uvm_fault#3214775@0: called!
1077373385.515871 uvm_fault#3214775@0: (map=0xd915030, vaddr=0x0, ft=0, at=1)
1077373385.515876 uvm_map_lookup_entry#3350213@0: called!
1077373385.515879 uvm_map_lookup_entry#3350213@0: (map=0xd915030,addr=0x0,ent=0xdffdcc8)
1077373385.515883 uvm_map_lookup_entry#3350213@0: <- failed!
1077373385.515886 uvm_fault#3214775@0: <- no mapping @ 0x0
1077373385.515900 uvm_fault#3214776@0: called!
...


the code from tramptest that's causing this fault is at 0x100c00, which is:

(gdb) x/9i buserr  
0x100bf0 <buserr>:      save  %sp, -192, %sp
0x100bf4 <buserr+4>:    cmp  %i0, 0xb
0x100bf8 <buserr+8>:    bne,pn   %icc, 0x100c14 <buserr+36>
0x100bfc <buserr+12>:   mov  2, %o0
0x100c00 <buserr+16>:   ld  [ %i1 + 4 ], %g1
0x100c04 <buserr+20>:   cmp  %g1, 2

so it's looking like the siginfo pointer isn't being set up correctly
for the signal handler.

-Chuck


On Thu, Feb 19, 2004 at 07:35:32PM +0100, Matthias Drochner wrote:
> 
> Hi -
> I don't have a ppc box to test with atm, but I've done
> related fixes to other architectures, and from code
> inspection it appears to me that a little fix should be
> applied to the sparc64 as well.
> Desired behaviour is that a SIGSEGV is delivered to a
> process, with a siginfo si_code of SEGV_ACCERR if code
> execution is attempted from virtual memory mapped without
> execution permission (especially the stack).
> The appended patched should implement this.
> 
> The regression test in regress/sys/uvm/stack_noexec
> should be sufficient to verify.
> 
> best regards
> Matthias
> 
>