re: port-sparc64/46274: sparc64 running netbsd 32bit code causes a lot of cores

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR port-sparc64/46274; it has been noted by 
GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-sparc64-maintainer%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: re: port-sparc64/46274: sparc64 running netbsd 32bit code causes a lot 
of cores
Date: Thu, 29 Mar 2012 14:58:48 +1100

 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: port-sparc64/46274: sparc64 running netbsd 32bit code causes a 
 > lot of cores
 > Date: Thu, 29 Mar 2012 01:35:23 +0200
 > 
 >  I trapped the kernel when sending the signal and verified the faulting
 >  address. In this case it was 0x140268087 (clearly not mapped anywhere),
 >  where 0x40268087 would be fine and probably what the process tries to
 >  access.
 
 nice catch.
 
 >  But I am not sure where to catch and fix it (nor where the 
 > pc-relative-address
 >  stub is generated).
 >  
 >  Should locore.s/trap.c truncate the fault address for 32bit processes
 >  before calling uvm_fault? Should uvm deal? Is the pc-relative addressing
 >  stub bogus?
 
 can you explain this a little more?  where in the code have you
 confirmed this, etc?
 
 i'd guess that we should mask addresses somewhere, but i'm more
 curious why it isn't happening already.
 
 i don't think uvm should have to deal with this.  we're not
 feeding it anything valid.  we're feeding it addresses outside
 of VM_*USER addresses.
 
 
 .mrg.