* [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email)
@ 2001-05-04 6:51 Weihaw CHUANG
2001-05-04 14:02 ` Don Dugger
2001-05-04 15:02 ` David Mosberger
0 siblings, 2 replies; 3+ messages in thread
From: Weihaw CHUANG @ 2001-05-04 6:51 UTC (permalink / raw)
To: linux-ia64
I think I've figured out my own question. However I still would like to
understand some of this kernel code in
<linux src>/arch/ia64/kernel/entry.S
If my application takes an exception, what is the entry point in entry.S?
I'd also like to verify that application stacked registers will be
stored on kernel stack during a context switch. My understanding is that
only the last procedure frame will be stored there. (Is this notion
correct?)
I'm still very unsure if my intuition is correct, hence the
questions. I only figured out the below through trial and error
hacking.
Anyways the solution appears to be (again correct me if anything is brain
damaged):
On Thu, 3 May 2001, Weihaw CHUANG wrote:
>
> int offset = cfm.sof - (regid-32)
> unsigned long long = ptrace(PTRACED_PEEKUSER, pid, PT_AR_BSP, 0);
> regvalue = ptrace(PTRACE_PEEKDATA, pid,
> (long ) ia64_rse_skip_regs((long*) bsp, offset), 0);
>
int offset = regid - 32;
unsigned long long bspstore = ptrace(PTRACED_PEEKUSER, pid,
PT_AR_BSPSTORE, 0);
unsigned long long regvalue = ptrace(PTRACE_PEEKDATA, pid,
(long) ia64_rse_skip_regs((long*) bspstore, offset),
0);
I'd like to be pendantic, and make sure the following intuition is
correct. Ptrace dumps seems to agree so far.
>
>
> That is, does this diagram make sense?
>
> alloc r35 = ar.pfs, 0, 3, 0, 0
> reg stack
> | r32 | r34 | r35 | (r35 is top of reg stack)
> negative offset from bsp is:
> 3 2 1 bsp
offset from
^bspstore
0 1 2
Thanks!!
-Wei
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email)
2001-05-04 6:51 [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email) Weihaw CHUANG
@ 2001-05-04 14:02 ` Don Dugger
2001-05-04 15:02 ` David Mosberger
1 sibling, 0 replies; 3+ messages in thread
From: Don Dugger @ 2001-05-04 14:02 UTC (permalink / raw)
To: linux-ia64
Wei-
The file `arch/ia64/kernel/ivt.S' contains the interrupt vector table.
This is where all exceptions go.
On Thu, May 03, 2001 at 11:51:26PM -0700, Weihaw CHUANG wrote:
>
> I think I've figured out my own question. However I still would like to
> understand some of this kernel code in
> <linux src>/arch/ia64/kernel/entry.S
>
> If my application takes an exception, what is the entry point in entry.S?
> I'd also like to verify that application stacked registers will be
> stored on kernel stack during a context switch. My understanding is that
> only the last procedure frame will be stored there. (Is this notion
> correct?)
>
> I'm still very unsure if my intuition is correct, hence the
> questions. I only figured out the below through trial and error
> hacking.
>
> Anyways the solution appears to be (again correct me if anything is brain
> damaged):
>
> On Thu, 3 May 2001, Weihaw CHUANG wrote:
>
> >
> > int offset = cfm.sof - (regid-32)
> > unsigned long long = ptrace(PTRACED_PEEKUSER, pid, PT_AR_BSP, 0);
> > regvalue = ptrace(PTRACE_PEEKDATA, pid,
> > (long ) ia64_rse_skip_regs((long*) bsp, offset), 0);
> >
>
> int offset = regid - 32;
> unsigned long long bspstore = ptrace(PTRACED_PEEKUSER, pid,
> PT_AR_BSPSTORE, 0);
> unsigned long long regvalue = ptrace(PTRACE_PEEKDATA, pid,
> (long) ia64_rse_skip_regs((long*) bspstore, offset),
> 0);
>
>
> I'd like to be pendantic, and make sure the following intuition is
> correct. Ptrace dumps seems to agree so far.
>
> >
> >
> > That is, does this diagram make sense?
> >
> > alloc r35 = ar.pfs, 0, 3, 0, 0
> > reg stack
> > | r32 | r34 | r35 | (r35 is top of reg stack)
> > negative offset from bsp is:
> > 3 2 1 bsp
> offset from
> ^bspstore
> 0 1 2
>
> Thanks!!
> -Wei
>
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email)
2001-05-04 6:51 [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email) Weihaw CHUANG
2001-05-04 14:02 ` Don Dugger
@ 2001-05-04 15:02 ` David Mosberger
1 sibling, 0 replies; 3+ messages in thread
From: David Mosberger @ 2001-05-04 15:02 UTC (permalink / raw)
To: linux-ia64
>>>>> On Thu, 3 May 2001 23:51:26 -0700 (PDT), Weihaw CHUANG <wchuang@cs.ucsd.edu> said:
Weihaw> Anyways the solution appears to be (again correct me if
Weihaw> anything is brain damaged):
Note that when using ptrace() to read PT_AR_BSP, you get a pointer to
the _end_ of the backing store, i.e., you get the value of ar.bsp as
if a "cover" instruction had been executed by the target task. Since
the task is blocked at the time you call ptrace(), the stacked
registers are indeed on the stack (they get written to the
backingstore by the "flushrs" instruction in the context switch
routine).
Thus, to read stacked register, you'd do something along the lines of:
unsigned long *rbs_end, *bsp;
rbs_end = ptrace(PTRACED_PEEKUSER, pid, PT_AR_BSP, 0);
bsp = ia64_rse_skip_regs(rbs_end, -cfm.sof);
regvalue = ptrace(PTRACE_PEEKDATA, pid,
ia64_rse_skip_regs(bsp, regid - 32), 0);
(The code in utrace.c is outdated in this respect.)
--david
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-05-04 15:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-05-04 6:51 [Linux-ia64] Re: location of statcked registers after exception (superceeds previous email) Weihaw CHUANG
2001-05-04 14:02 ` Don Dugger
2001-05-04 15:02 ` David Mosberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox