RE: [ECOS] Re: ISR not causing an DSR in some rare conditions

[Gary Thomas <gary at mlbassoc dot com>]

On Mon, 2006-01-23 at 15:08 -0800, Jay Foster wrote:
> It seems troubling to me that the context switching code does not save and
> restore all registers.  Any register(s) not saved and restored by the
> context switching code could not be used anywhere, since you would never
> know when a context switch occurred, clobbering the registers.  I agree that
> from the point of view of the ARM ABI this is acceptable, since you know
> when you called another function, but this is not so for context switches.
> I suspect that there is something else going on here, of which I am
> ignorant.
> 

It's not as bad as you think.  "User" code does not call the context
switch code directly - you can only get here by passing through the
kernel, in particular via the scheduler.  When this thread runs 
again, it will unwind through the kernel to wherever it was and all
pertinent registers will be restored.

The code paths that do matter, namely exception and interrupt 
processing, can [and do] save everything as they can happen anywhere.

> Jay
> 
> -----Original Message-----
> From: Sergei Organov [mailto:osv@javad.com]
> Sent: Monday, January 23, 2006 2:07 AM
> To: ecos-patches@sources.redhat.com
> Subject: Re: [ECOS] Re: ISR not causing an DSR in some rare conditions
> 
> 
> Jay Foster <jay@systech.com> writes:
> > I've re-examined this patch, and have noticed that it does not 'exactly'
> > result in the same operation as the original code.
> >
> > The original code:
> >         sub     ip,sp,#20
> >         stmfd   ip!,{sp,lr}
> >         mov     sp,ip
> >         stmfd   sp!,{r0-r10,fp,ip}
> >  
> > The proposed code:
> >         mov     ip,sp
> >         sub     sp,sp,#(ARMREG_SIZE - armreg_pc) // skip svc_sp, svc_lr,
> > vector, cpsr, and pc
> >         stmfd   sp!,{ip,lr}
> >         stmfd   sp!,{r0-r10,fp,ip}
> >  
> > Note that the value of 'ip' saved on the stack by the 4th instruction
> > (stmfd) is different for these two cases.  In the original code, 'ip' was
> > the same as the sp just prior to the stmfd instruction.  In the proposed
> > code, 'ip' is the same as the sp upon entry to the function.
> >
> > By adding an extra instruction, this can be corrected to be the same:
> >         mov     ip,sp
> >         sub     sp,sp,#(ARMREG_SIZE - armreg_pc) // skip svc_sp, svc_lr,
> > vector, cpsr, and pc
> >         stmfd   sp!,{ip,lr}
> >         mov     ip,sp
> >         stmfd   sp!,{r0-r10,fp,ip}
> >  
> > It doesn't appear to make any difference.  Is this because it doesn't
> > matter?
> 
> I believe it doesn't in fact matter as in both cases the ip stored on
> the stack doesn't match those on the entry to the function. Thus, in
> both cases the ip value is not preserved by the function. That's OK from
> the point of view of ARM ABI as it says that caller must expect ip to be
> clobbered by any function.
> 
> >From the point of view of eCos, both variants are equally not excellent
> when saving of full CPU context is configured as the ip saved in the
> thread context doesn't match the ip of the thread though it could only
> affect the ease of debugging, I think.
> 
> > If it doesn't matter, then there is no reason to add the extra mov
> > instruction.
> 
> There is no reason to add extra instruction, I think.
> 
> > Are interrupts even enabled on entry to this function?  If not, then
> > none of this matters.
> 
> I believe that interrupts are enabled during context switch, so the
> change I've proposed does matter.
> 
> -- Sergei.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss