[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: port-sparc64/46274: sparc64 running netbsd 32bit code causes a lot of cores
The following reply was made to PR port-sparc64/46274; it has been noted by
From: matthew green <mrg%eterna.com.au@localhost>
Subject: re: port-sparc64/46274: sparc64 running netbsd 32bit code causes a lot
Date: Thu, 29 Mar 2012 14:58:48 +1100
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> 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
> But I am not sure where to catch and fix it (nor where the
> 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.
Main Index |
Thread Index |