Re: [Xen-devel] [PATCH ARM v6 14/14] mini-os: arm: show registers, stack and exception vector on fault

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-07-28 at 12:49 +0100, Thomas Leonard wrote:
> On 28 July 2014 12:13, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2014-07-16 at 12:07 +0100, Thomas Leonard wrote:
> >> +@ We want to store a unique value to identify this handler, without 
> >> corrupting
> >> +@ any of the registers. So, we store r15 (which will point just after the 
> >> branch).
> >> +@ Later, we subtract 12 so the user gets pointed at the start of the 
> >> exception
> >> +@ handler.
> >
> > You do corrupt r13 though.
> 
> r13 is banked for all faults except SVC.

Oh yes, I'd a) spent too much time with the hyp exception model (which
differs here) and b) momentarily forgotten that r13 is sp.

>  Possibly for SVC we should do
> something different (though you'll always lose r14 anyway if SVC code
> makes an SVC call for some reason).
> 
> > The way many OSes handle this is to make at least the initial saving
> > (i.e. that which you have at fault:) into a macro and inlining a copy at
> > each entry point. They also arrange for each SP_$mode to always point to
> > something useful (in your case fault_dump, I guess) to avoid using a
> > register as the save target.
> 
> You mean dumping the registers to the SVC stack in the SVC fault
> handler? That might cause another fault if the stack is full, but I
> may be misunderstanding you.

It was what I meant but now that you've reminded me about r13 its a bit
moot.

> > BTW you can infer the same information as you do all this -12 stuff for
> > from the saved CPSR.
> 
> You mean by looking at the processor mode? There are two exceptions
> that both go to Abort mode though.

Once again I've been spending too much time with the hyp exception
model ;-)

>  I haven't checked to see whether
> the information could be recovered some other way; substracting 12
> seemed pretty easy.

OK.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel