This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Re: ISR not causing an DSR in some rare conditions
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Jay Foster <jay at systech dot com>
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Mon, 23 Jan 2006 16:59:12 -0700
- Subject: RE: [ECOS] Re: ISR not causing an DSR in some rare conditions
- References: <74C9525D67A5FF4791614FDB06593BB1028544@mail.systech.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