From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16821 invoked by alias); 1 Dec 2005 00:47:31 -0000 Received: (qmail 16815 invoked by uid 22791); 1 Dec 2005 00:47:31 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_POST X-Spam-Check-By: sourceware.org Received: from fmr17.intel.com (HELO orsfmr002.jf.intel.com) (134.134.136.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Dec 2005 00:47:30 +0000 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jB10lTiA030571 for ; Thu, 1 Dec 2005 00:47:29 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id jB10lRYS031161 for ; Thu, 1 Dec 2005 00:47:28 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005120108472607151 for ; Thu, 01 Dec 2005 08:47:26 +0800 Received: from pdsmsx404.ccr.corp.intel.com ([172.16.12.64]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 08:47:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: RE: jprobe question Date: Thu, 01 Dec 2005 00:47:00 -0000 Message-ID: <8126E4F969BA254AB43EA03C59F44E84040B3A0A@pdsmsx404> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: jprobe question Thread-Index: AcX1FkqCAsXTDr0nT6ygfsW3UeKViQAOTxWQACfE1KAACD/8cA== From: "Zhang, Yanmin" To: "Keshavamurthy, Anil S" Cc: , "Mao, Bibo" X-OriginalArrivalTime: 01 Dec 2005 00:47:27.0506 (UTC) FILETIME=[CD59EF20:01C5F610] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00306.txt.bz2 >>-----Original Message----- >>From: Keshavamurthy, Anil S >>Sent: 2005=C4=EA12=D4=C21=C8=D5 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 u= nwind frame on the top of the stack. Anyway, I will work out a new patch us= ing unwind.