Re: [PATCH v19 02/13] linux-user: Add LoongArch signal support

[gaosong]

On 2022/6/24 上午9:20, Richard Henderson wrote:

> On
>       6/23/22 17:45, maobibo wrote:
>       
> >         
> >         
> >         在 2022/6/24 07:34, Richard Henderson 写道:
> >         
> > > On 6/23/22
> > >           01:55, Song Gao wrote:
> > >           
> > > > +static void
> > > >             setup_sigcontext(CPULoongArchState *env,
> > > >             
> > > >             +                             struct target_sigcontext *sc,
> > > >             
> > > >             +                             struct extctx_layout *extctx)
> > > >             
> > > >             +{
> > > >             
> > > >             +    int i;
> > > >             
> > > >             +
> > > >             
> > > >             +    if (extctx->flags & SC_USED_FP) {
> > > >             
> > > >             +        __put_user(extctx->fpu.addr,
> > > >             &sc->sc_extcontext[0]);
> > > >             
> > > >             +    } else {
> > > >             
> > > >             +        __put_user(extctx->end.addr,
> > > >             &sc->sc_extcontext[0]);
> > > >             
> > > >             +    }
> > > >             
> > > >           
> > >           
> > >           This is incorrect.  Where did this come from?  It certainly
> > >           doesn't appear in the kernel's version of setup_sigcontext. 
> > >           The only reason the result works for you is that this is
> > >           overwritten by copy_fpu_to_sigframe within setup_sigframe.
> > >           
> > >         
> >         
> >         The val of flags is SC_USED_FP alway in function
> >         setup_extcontext in this version. We want to optimization in
> >         future if FP is not used for application where sigcontext for FP
> >         is not necessary. Also it can will be extended for 128bit/256bit
> >         vector FPU.
> >         
> >       
>       
>       No, that's not what I mean.  The store of the address is
>       incorrect.
>       
>       This is no such address stored in the frame at this location.
>       
>       
>       If you believe that I am incorrect, please point to the line
>       within the kernel source to which this corresponds.
>

You're right,   I'll corrrect on next version.

    Thanks.
    Song Gao