Messages in this thread | | | Date | Thu, 29 Mar 2012 17:52:50 -0700 | Subject | Re: [RFC 00/15] perf: Add backtrace post dwarf unwind | From | Stephane Eranian <> |
| |
On Thu, Mar 29, 2012 at 5:44 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > On Thu, 2012-03-29 at 17:38 -0700, Stephane Eranian wrote: >> What I'd like to have is something similar to: >> attr->sample_type |= PERF_SAMPLE_REGS >> attr->sample_regs = EAX | EBX | EDI | ESI |..... >> attr->sample_reg_mode = { INTR, PRECISE, USER } >> >> Then in each sample for the event you dump the u64 values >> of the requested registers. The order is that of the enum >> enum regs {}. That enum is arch specific. >> >> When you are in precise mode on Intel, you extract the regs >> from PEBS. You already know the registers supported by PEBS >> so you can reject any request for unsupported regs. >> >> When you are in intr they you get the regs from pt_regs. >> The user mode case is taken care of by the this patch series >> already. >> >> I am not sure the sample_reg_mode needs to be a bitmask, i.e., >> do we need the reg state for INTR+PRECISE or USER+INTR? >> But if so, then we would need attr->sample_regs[3] as not all >> registers may be available in each mode. > > I'm really having trouble seeing how useful this is. You mentioned > sampling function arguments, but most samples would be in the middle of > functions where the regs are completely unrelated to arguments. Also > isn't the 'normal' C ABI passing args on stack rather than registers? > If you look at the SNB events, you'll see that br_inst_retired:near_call supports PEBS. The sample is taken at retirement of the call, i.e., the first instruction of the function, exactly where you want it to be.
Unless I am mistaken, the x86_64 calling convention passes the first 6 integer arguments in registers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |