On 2015/07/01 3:40, Brendan Gregg wrote: > G'Day Masami, > > On Tue, Jun 30, 2015 at 12:37 AM, Masami Hiramatsu > <[email protected]> wrote: >> On 2015/06/30 0:00, Arnaldo Carvalho de Melo wrote: >>> Em Sun, Jun 28, 2015 at 05:46:51PM +0200, Benjamin King escreveu: >>>> Hi Brendan >>>> >>>>> Is there a trick to getting perf to probe a user-level address without >>>>> debuginfo? Eg (on Linux 4.0): >>>>> [...] >>>>> I can do this using ftrace ok, eg, "p:tick_0x583 /root/tick:0x583" >>>>> works. Thanks, >>>> >>>> Not quite what you have asked for, but you can add the probe via ftrace and >>>> then use it from perf. Probes from /sys/kernel/debug/tracing/uprobe_events >>>> will show up in 'perf list' as well. >>> >>> Masami, >>> >>> Is this already possible? >> >> Yes, it should be possible. However, I don't recommend you to >> probe the address inside a function without debuginfo. You must >> check the instruction boundary in that case. > > Ah, because otherwise I could accidentally trace at a non-zero offsite > inside an instruction? That probably explains the only failure I saw > on uprobes on linux 4.0. > > Here's the original use case: > > # readelf -n /root/node/node > [...] > stapsdt 0x00000082 NT_STAPSDT (SystemTap probe descriptors) > Provider: node > Name: http__client__request > Location: 0x0000000000bf48ff, Base: 0x0000000000f22464, Semaphore: > 0x0000000001243024 > Arguments: 8@%rax 8@%rdx 8@-136(%rbp) -4@-140(%rbp) 8@-72(%rbp) > 8@-80(%rbp) -4@-144(%rbp) > [...] > > These user SDT probes (or "USDT probes") can't currently be traced > using perf (although Hemant Kumar was working on a patch).
Yes, and I'm working on it. > I can trace them via ftrace, and have already written a helper script. > But that's another story. I'm interested in doing this from perf as > well! (Without needing to create the probes via ftrace.) > > I have their instruction offset above from readelf (and need to > subtract the base load address). Here's what doesn't work: > > A) Tracing via the absolute address. Eg, "perf probe -x node '@+0x7f48ff' > > B) Tracing via the offset from main. Eg, "perf probe -x node > 'main+0x...", since perf complains I'm tracing at an offset bigger > than main. > > C) Tracing via the offset from the function that contains the probe. > In this case, because the function name is too big! (Due to C++) Eg: > > # ./perf probe -x /root/node/node --filter="*" > '_ZN4node26DTRACE_HTTP_CLIENT_REQUESTERKN2v820FunctionCallbackInfoINS0_5ValueEEE+0x42f' > Added new event: > Error: Failed to add events. > > I've attached a trivial patch for (C), it just increases the buffer > size in __add_probe_trace_events() from 64 to 128. It's still a bit of > a nuisance to resolve the containing function (addr2line) when I have > the absolute address... The buffer size will be fixed with strbuf in my series. https://lkml.org/lkml/2015/5/31/84 Anyway, thank you for reporting it. I'll check why it doesn't work. Thanks! > > Brendan > -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
