RE: jprobe question

["Zhang, Yanmin" <yanmin dot zhang at intel dot com>]

>>-----Original Message-----
>>From: Keshavamurthy, Anil S
>>Sent: 2005年12月1日 4:56
>>To: Zhang, Yanmin
>>Cc: 'systemtap@sources.redhat.com'; Mao, Bibo
>>Subject: RE: jprobe question
>>
>>>Here are the patches. In function non_syscall, I save the
>>>ar.bsp (after instruction cover) to the scratch area below
>>>pt_regs, then calls preserve_scratch_area.
>>>preserve_scratch_area will reserve 1 new 16-byte area for next
>>>call to ia64_bad_break. Later on, kprobe handler uses
>>>pt_regs->cr_ifs and the saved ar.bsp to get the real ar.bsp
>>>and parameter number. This approach also considers user space
>>>probe. kprobe_save_bsp patch has no any impact on critical fault patch.
>>>The jprobe patch is to save the function parameters when the
>>>jprobe is hit and restore them after break.
>>
>>Yanmin,
>>	I am not sure whether using the scratch area below the pt_regs
>>to save ar.bsp would be the right thing to do and more over it does look like
>>a hack.
>>Clean solution would be to have a field in pt_regs to save ar.bsp,
[YM] Yes. But some bigwigs might be unhappy to add new members into pt_regs.

 until we
>>have it, here is what you can do for now.
>>
>>In the setjmp_pre_handler() get the ar.bsp by unwinding the stack
>>and then calling unw_get_bsp() to get the ar.bsp. Save this ar.bsp in the kcb
>>structure and later
>>in longjmp_break_handler() you can use this ar.bsp without unwinding the stack.
[YM] unwind costs too much time because it will create a switch_stack and unwind frame on the top of the stack. Anyway, I will work out a new patch using unwind.