Question about signal syscalls !

Question about signal syscalls !

[Franck Bui-Huu]

Hi,

I'm probably missing something very obvious so the subject could have
been "Dumb question of the week". So please be nice when answering ;)

I'm wondering why we need to save/restore the static registers
(s0...s7) when dealing with some  signal system calls. Specially all
of them which are declared by using save_static_function() macros.

Thanks
-- 
               Franck

Re: Question about signal syscalls !

[Ralf Baechle]

On Thu, Feb 01, 2007 at 11:43:13AM +0100, Franck Bui-Huu wrote:

> I'm probably missing something very obvious so the subject could have
> been "Dumb question of the week". So please be nice when answering ;)
> 
> I'm wondering why we need to save/restore the static registers
> (s0...s7) when dealing with some  signal system calls. Specially all
> of them which are declared by using save_static_function() macros.

The values of those registers need to be preserved so they can later be
copied into the signal frame.

  Ralf

Re: Question about signal syscalls !

[Franck Bui-Huu]

Hi Ralf,

On 2/1/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> The values of those registers need to be preserved so they can later be
> copied into the signal frame.
>

Let's take for example sys_sigreturn(). In my understanding this
syscall is used automatically when the signal handler returns. At this
time, I don't see the point to save the static registers since they
have been already saved by setup_sigcontext().

Actually I don't see why they need to be saved/restored at all...

Let's say that process P1 sends a signal X to process P2 which has a
handler defined for signal X and assume that the static registers are
not saved at all.

Signal X is received by P2. The signal handler is now executed in user
mode. At this point what are the values of the static registers ? I
would say they have the same values (let's call this state S) when P2
got interrupted. Once the signal handler returns into the kernel mode
by executing 'syscall __NR_sigreturn' instructions, static registers
still have state S and this state is normally preserved during
sys_sigreturn syscall execution. So when resuming the normal execution
of P2, the static registers have the correct values.

What am I missing ?

Thanks
-- 
               Franck

Re: Question about signal syscalls !

[David Daney]

Franck Bui-Huu wrote:
> Hi Ralf,
> 
> On 2/1/07, Ralf Baechle <ralf@linux-mips.org> wrote:
>> The values of those registers need to be preserved so they can later be
>> copied into the signal frame.
>>
> 
> Let's take for example sys_sigreturn(). In my understanding this
> syscall is used automatically when the signal handler returns. At this
> time, I don't see the point to save the static registers since they
> have been already saved by setup_sigcontext().
> 
> Actually I don't see why they need to be saved/restored at all...
> 
> Let's say that process P1 sends a signal X to process P2 which has a
> handler defined for signal X and assume that the static registers are
> not saved at all.
> 
> Signal X is received by P2. The signal handler is now executed in user
> mode. At this point what are the values of the static registers ? I
> would say they have the same values (let's call this state S) when P2
> got interrupted. Once the signal handler returns into the kernel mode
> by executing 'syscall __NR_sigreturn' instructions, static registers
> still have state S and this state is normally preserved during
> sys_sigreturn syscall execution. So when resuming the normal execution
> of P2, the static registers have the correct values.
> 
> What am I missing ?

I don't think *any* registers *need* to be saved on sys_sigreturn(). 
The values in sigcontext on the user stack associated with the system 
call are all used instead of the actual register values.

David Daney

Re: Question about signal syscalls !

[Ralf Baechle]

On Thu, Feb 01, 2007 at 03:54:40PM +0100, Franck Bui-Huu wrote:

> Let's take for example sys_sigreturn(). In my understanding this
> syscall is used automatically when the signal handler returns. At this
> time, I don't see the point to save the static registers since they
> have been already saved by setup_sigcontext().
> 
> Actually I don't see why they need to be saved/restored at all...

There is no need.  Seems you found a harmless but longstanding but
introduced by c40738a70f3e02e8554b78af334dc95356a78989.

  Ralf

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/1/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Thu, Feb 01, 2007 at 03:54:40PM +0100, Franck Bui-Huu wrote:
>
> > Let's take for example sys_sigreturn(). In my understanding this
> > syscall is used automatically when the signal handler returns. At this
> > time, I don't see the point to save the static registers since they
> > have been already saved by setup_sigcontext().
> >
> > Actually I don't see why they need to be saved/restored at all...
>
> There is no need.  Seems you found a harmless but longstanding but
> introduced by c40738a70f3e02e8554b78af334dc95356a78989.
>

OK. Just to be sure about what you meant, there are currently 2 places
where we save s0-s7 regs. One in setup_sigcontext() and one done by
save_static_function(). Do you mean that both savings are useless ?
It's actually what I'm thinking and if so
setup_sigcontext()/restore_sigcontext() have a harmless bug too.

-- 
               Franck

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/1/07, David Daney <ddaney@avtrex.com> wrote:
> I don't think *any* registers *need* to be saved on sys_sigreturn().
> The values in sigcontext on the user stack associated with the system
> call are all used instead of the actual register values.
>

Sorry but I don't understand what you mean. Could you explain ?

Thanks
-- 
               Franck

Re: Question about signal syscalls !

[David Daney]

Franck Bui-Huu wrote:
> On 2/1/07, David Daney <ddaney@avtrex.com> wrote:
>> I don't think *any* registers *need* to be saved on sys_sigreturn().
>> The values in sigcontext on the user stack associated with the system
>> call are all used instead of the actual register values.
>>
>
> Sorry but I don't understand what you mean. Could you explain ?
sys_sigreturn does not return to the caller in the conventional sense.  
The entire user context (i.e. the value of *all* registers) is replaced 
with the values stored in the sigcontext structure on the caller's 
stack.  If all registers are being restored from the sigcontext, then 
there is no need to save the current values of the registers, because 
they will never be used.

David Daney

Re: Question about signal syscalls !

[Franck Bui-Huu]

David Daney wrote:
> sys_sigreturn does not return to the caller in the conventional sense.

I expect you're talking about this bite of code taken from _sys_sigreturn():

        /*
         * Don't let your children do this ...
         */
        __asm__ __volatile__(
                "move\t$29, %0\n\t"
                "j\tsyscall_exit"
                :/* no outputs */
                :"r" (&regs));

> The entire user context (i.e. the value of *all* registers) is replaced
> with the values stored in the sigcontext structure on the caller's
> stack.  If all registers are being restored from the sigcontext, then
> there is no need to save the current values of the registers, because
> they will never be used.
>

But I don't see where _all_ registers are saved. Only static registers
are saved by save_static_function() right before calling
_sys_sigreturn() and I agree I don't why we need to save those.

And now I'm starting to think that we don't need to save static regs in
setup_sigcontext() either...

-- 
               Franck

Re: Question about signal syscalls !

[Daniel Jacobowitz]

On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote:
> And now I'm starting to think that we don't need to save static regs in
> setup_sigcontext() either...

It's possible not to (iirc at least one arch does that) but please
don't change it now.  This is a userland ABI issue; GDB knows that the
registers are saved, and there are slots for them in
sigcontext/ucontext so it would be unexpected if they were not filled
in.  Could break things like pth.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Question about signal syscalls !

[David Daney]

Franck Bui-Huu wrote:
> David Daney wrote:
>> sys_sigreturn does not return to the caller in the conventional sense.
>
> I expect you're talking about this bite of code taken from 
> _sys_sigreturn():
>
>        /*
>         * Don't let your children do this ...
>         */
>        __asm__ __volatile__(
>                "move\t$29, %0\n\t"
>                "j\tsyscall_exit"
>                :/* no outputs */
>                :"r" (&regs));
>
>> The entire user context (i.e. the value of *all* registers) is replaced
>> with the values stored in the sigcontext structure on the caller's
>> stack.  If all registers are being restored from the sigcontext, then
>> there is no need to save the current values of the registers, because
>> they will never be used.
>>
>
> But I don't see where _all_ registers are saved. Only static registers
> are saved by save_static_function() right before calling
> _sys_sigreturn() and I agree I don't why we need to save those.
>
> And now I'm starting to think that we don't need to save static regs in
> setup_sigcontext() either...
>
All registers *must* be saved in the sigcontext.  That is part of the 
contract the kernel has with user code.

On return from an asynchronous signal, *all* registers must contain the 
same values they had before the process was interrupted.

David Daney

David Daney

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/2/07, David Daney <ddaney@avtrex.com> wrote:
> Franck Bui-Huu wrote:
> > David Daney wrote:
> >> The entire user context (i.e. the value of *all* registers) is replaced
> >> with the values stored in the sigcontext structure on the caller's
> >> stack.  If all registers are being restored from the sigcontext, then
> >> there is no need to save the current values of the registers, because
> >> they will never be used.
> >>
> >

Again, why do you think that all values of the registers are saved on
sys_sigreturn() ?


> > And now I'm starting to think that we don't need to save static regs in
> > setup_sigcontext() either...
> >
> All registers *must* be saved in the sigcontext.  That is part of the
> contract the kernel has with user code.
>

I'm just talking about _static_ registers which are s0-s7...

> On return from an asynchronous signal, *all* registers must contain the
> same values they had before the process was interrupted.
>

yes I agree and I've never said the contrary.
-- 
               Franck

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/2/07, Daniel Jacobowitz <dan@debian.org> wrote:
> On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote:
> > And now I'm starting to think that we don't need to save static regs in
> > setup_sigcontext() either...
>
> It's possible not to (iirc at least one arch does that) but please

can you tell which one ?

> don't change it now.  This is a userland ABI issue; GDB knows that the

don't worry I don't want to change anything, I'm just trying to understand.

> registers are saved, and there are slots for them in
> sigcontext/ucontext so it would be unexpected if they were not filled
> in.  Could break things like pth.
>

ok it's a good point to keep in mind.

thanks
-- 
               Franck

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/2/07, Daniel Jacobowitz <dan@debian.org> wrote:
> On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote:
> > And now I'm starting to think that we don't need to save static regs in
> > setup_sigcontext() either...
>
> It's possible not to (iirc at least one arch does that) but please
>

crazy idea: do you think it could be possible not to when dealing with
interrupts ?

-- 
               Franck

Re: Question about signal syscalls !

[David Daney]

Franck Bui-Huu wrote:
> On 2/2/07, David Daney <ddaney@avtrex.com> wrote:
>> Franck Bui-Huu wrote:
>> > David Daney wrote:
>> >> The entire user context (i.e. the value of *all* registers) is 
>> replaced
>> >> with the values stored in the sigcontext structure on the caller's
>> >> stack.  If all registers are being restored from the sigcontext, then
>> >> there is no need to save the current values of the registers, because
>> >> they will never be used.
>> >>
>> >
> 
> Again, why do you think that all values of the registers are saved on
> sys_sigreturn() ?

I don't think that.  I don't think I ever said that.

> 
> 
>> > And now I'm starting to think that we don't need to save static regs in
>> > setup_sigcontext() either...
>> >
>> All registers *must* be saved in the sigcontext.  That is part of the
>> contract the kernel has with user code.
>>
> 
> I'm just talking about _static_ registers which are s0-s7...
> 
>> On return from an asynchronous signal, *all* registers must contain the
>> same values they had before the process was interrupted.
>>
> 
> yes I agree and I've never said the contrary.

I thought you were suggesting not saving s0-s7.  If you don't save them, 
you cannot restore them.  And they have to be restored from the 
sigcontext in the user's address space.   This allows user space signal 
handlers to emulate trapping instructions, and the like.

David Daney

Re: Question about signal syscalls !

[Daniel Jacobowitz]

On Fri, Feb 02, 2007 at 12:41:07PM -0800, David Daney wrote:
> I thought you were suggesting not saving s0-s7.  If you don't save them, 
> you cannot restore them.  And they have to be restored from the 
> sigcontext in the user's address space.   This allows user space signal 
> handlers to emulate trapping instructions, and the like.

Not necessarily, because you can trust the signal handler to restore
them, and it can save them itself if it needs to.  As I said, I think
there's at least one architecture which does it this way.  I'm afraid I
don't know which one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Question about signal syscalls !

[Ralf Baechle]

On Sun, Feb 04, 2007 at 07:55:16PM -0500, Daniel Jacobowitz wrote:

> On Fri, Feb 02, 2007 at 12:41:07PM -0800, David Daney wrote:
> > I thought you were suggesting not saving s0-s7.  If you don't save them, 
> > you cannot restore them.  And they have to be restored from the 
> > sigcontext in the user's address space.   This allows user space signal 
> > handlers to emulate trapping instructions, and the like.
> 
> Not necessarily, because you can trust the signal handler to restore
> them, and it can save them itself if it needs to.  As I said, I think
> there's at least one architecture which does it this way.  I'm afraid I
> don't know which one.

Not saving the s-registers into the signal frame would be a neat
optimization.  It wouldn't only make things a little faster it would
also free space in the signal frame which is needed for CPU
architecture extensions that have more state to save.  I had to burn
almost the entire available space for the DSP extensions, so I wonder
if we could get GDB to work?  The alternative is probably a new version
of the sigrestore.

  Ralf

Re: Question about signal syscalls !

[Daniel Jacobowitz]

On Mon, Feb 05, 2007 at 01:10:48AM +0000, Ralf Baechle wrote:
> Not saving the s-registers into the signal frame would be a neat
> optimization.  It wouldn't only make things a little faster it would
> also free space in the signal frame which is needed for CPU
> architecture extensions that have more state to save.  I had to burn
> almost the entire available space for the DSP extensions, so I wonder
> if we could get GDB to work?  The alternative is probably a new version
> of the sigrestore.

I'm sure that, if we tried, we could get GDB to work.  Every time this
comes up I just worry about other things that we don't know about which
use the saved information.  These structures are just in too many
places to change comfortably.

If you're worried about DSP extensions, you might want to take a look
at the work Nico and I did for ARM in the past year or so; it tags
extra register sets in the ucontext.  It was a pain to get together
though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Question about signal syscalls !

[David Daney]

Daniel Jacobowitz wrote:
> On Mon, Feb 05, 2007 at 01:10:48AM +0000, Ralf Baechle wrote:
>   
>> Not saving the s-registers into the signal frame would be a neat
>> optimization.  It wouldn't only make things a little faster it would
>> also free space in the signal frame which is needed for CPU
>> architecture extensions that have more state to save.  I had to burn
>> almost the entire available space for the DSP extensions, so I wonder
>> if we could get GDB to work?  The alternative is probably a new version
>> of the sigrestore.
>>     
>
> I'm sure that, if we tried, we could get GDB to work.  Every time this
> comes up I just worry about other things that we don't know about which
> use the saved information.  These structures are just in too many
> places to change comfortably.
>   
If you are keeping track, add MD_FALLBACK_FRAME_STATE in libgcc, which 
allows throwing C++ and java exceptions through signal handlers.

If gdb can be made to work, so can libgcc.  The thing I worry about is I 
think people upgrade their kernel much more often than their 
toolchains.  So you could be in a position of having to use a very new 
GCC.  That might make some uncomfortable.

David Daney

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/5/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> Not saving the s-registers into the signal frame would be a neat
> optimization.  It wouldn't only make things a little faster it would

Actually it seems to me that setup_sigcontext() is almost completly
useless if the signal handler is dealt when returning from a system
call since just a very few registers are saved in the 'struct pt_regs'
structure. So setup_sigcontext() ends up saving a lot of random
values.
-- 
               Franck

Re: Question about signal syscalls !

[Franck Bui-Huu]

On 2/5/07, Daniel Jacobowitz <dan@debian.org> wrote:
> I'm sure that, if we tried, we could get GDB to work.  Every time this
> comes up I just worry about other things that we don't know about which
> use the saved information.  These structures are just in too many
> places to change comfortably.
>

It seems pretty dangerous if some tools use this saved hw context.
Because if the signal handler is handled during a return from a system
call (not from interrupt) then most information in the saved
information are random...

Well maybe we could just make a new version sig context functions
which does not save/restore static registers and make it an disabled
by default. That would let some people to play with and to see if it
break some user tools ?

-- 
               Franck