Re: [GIT] Sparc

[David Miller]

From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Date: Wed, 22 Sep 2010 21:43:24 +0100

> 	Actually, I wonder why don't we do the following:
> 1) check wsaved first, do fault_in_user_windows() if needed (and probably do
> Something Cruel(tm) if we fail copy_to_user() in there)
> 2) in a loop check if we need to reschedule / if we need to handle signals
> 3) don't bother with wsaved checks in setup_frame() variants at all -
> wsaved can't grow back at that point; we also can use flush_user_windows()
> instead of full synchronize_user_stack() in there.
> 
> It's definitely a separate patch, but it looks like it might be worth
> doing...  Comments?

Ok, let me think about this.

I think there are two things:

1) I think I originally intended to allow the signal dispatch to
   succeed even if we had windows we couldn't fault in.

   The idea is that the wsaved windows would be put into the signal
   frame.

   This never was implemented, however...

2) It would be nice to, in this case, still be able to let the debugger
   have a look.

   And part of "having a look" would mean letting it see the registers
   from the windows we couldn't save onto the stack.

   Otherwise GDB is just going to try and access the stack pages we
   were unable to.

Making #2 work could be done with an implementation of #1, since GDB
would need to be able to fetch the values easily from somewhere and
the signal frame storage we create for #1 would be as good as any.

I can't see much utility for a user signal handler for #1, however,
other than getting an accurate stack backtrace to emit a crash log
message or similar.

Alternatively, #2 could be implemented using a special ptrace getregs
call created specifically to fetch the windowed registers.  And
the regset implementation of that could be used for dumping them
into core files as well, and this specifically I've been meaning to
do at some point.

Again, let me think about this some more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/