On Wed, 2016-08-03 at 12:05 +0100, Peter Maydell wrote: > On 3 August 2016 at 09:02, Benjamin Herrenschmidt > > <[email protected]> wrote: > > > > Other archs don't do it, some programs catch signals just fine > > and those dumps just clutter the output. Keep the dumps for cases > > that aren't supposed to happen such as unknown codes. > > > > > > Signed-off-by: Benjamin Herrenschmidt <[email protected]> > > --- > > linux-user/main.c | 14 -------------- > > 1 file changed, 14 deletions(-) > > > > diff --git a/linux-user/main.c b/linux-user/main.c > > index eb9975c..8fbc5a6 100644 > > --- a/linux-user/main.c > > +++ b/linux-user/main.c > > @@ -1651,9 +1651,6 @@ void cpu_loop(CPUPPCState *env) > > "Aborting\n"); > > break; > > case POWERPC_EXCP_DSI: /* Data storage exception > > */ > > - EXCP_DUMP(env, "Invalid data memory access: 0x" TARGET_FMT_lx > > "\n", > > - env->spr[SPR_DAR]); > > - /* XXX: check this. Seems bugged */ > > Are you removing these XXX comments because you've checked the > error code cases below? If so it would be useful to say so > in the commit message...
Well I fix some of it in another patch... To the best of my understanding we only ever generate 0x40000000 and 0x42000000 via ppc_cpu_handle_mmu_fault() in user_only_helper.c unless there's another path to DSI in user mode that I missed. That being said, the comment isn't useful anyway. Nobody looks at it :-) I can respin with the comment back in or do put some blurb in the cset comment, let me know. BTW. I noticed, the generic path from the original signal coming from the host kernel through to here loses the information that would allow us to differenciate between a map error (no mapping) or a protection fault. It's a bit unfortunate, not sure if we can do much about it though without stopping to hijack the existing MMU translate hook in the CPU class and using a user mode dediated one that takes that sort of info as an argument. Cheers, Ben.
