From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt at goodmis.org (Steven Rostedt) Date: Mon, 6 May 2019 13:06:43 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190502202146.GZ2623@hirez.programming.kicks-ass.net> <20190502185225.0cdfc8bc@gandalf.local.home> <20190502193129.664c5b2e@gandalf.local.home> <20190502195052.0af473cf@gandalf.local.home> <20190503092959.GB2623@hirez.programming.kicks-ass.net> <20190503092247.20cc1ff0@gandalf.local.home> <2045370D-38D8-406C-9E94-C1D483E232C9@amacapital.net> <20190506081951.GJ2606@hirez.programming.kicks-ass.net> <20190506095631.6f71ad7c@gandalf.local.home> Message-ID: <20190506130643.62c35eeb@gandalf.local.home> On Mon, 6 May 2019 09:17:19 -0700 Linus Torvalds wrote: > So what is it that doesn't actually work? I've looked at the patch > even more, and I can't for the life of me see how it wouldn't work. > > Of course, I didn't test any of the actual ftrace parts, since I > short-circuited them intentionally with the above test function hack. > I have no idea what the semantics for those > ftrace_location(ip)/is_ftrace_caller(ip) cases are supposed to be, I > only tested that yes, the infrastructure clearly emulates a call > instruction. Can you try booting with: CONFIG_KPROBE_EVENTS=y CONFIG_UPROBE_EVENTS=y CONFIG_DYNAMIC_EVENTS=y CONFIG_PROBE_EVENTS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y CONFIG_FTRACE_SELFTEST=y CONFIG_FTRACE_STARTUP_TEST=y CONFIG_TRACEPOINT_BENCHMARK=y CONFIG_RING_BUFFER_BENCHMARK=y CONFIG_RING_BUFFER_STARTUP_TEST=y And see if it boots? -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt@goodmis.org (Steven Rostedt) Date: Mon, 6 May 2019 13:06:43 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190502202146.GZ2623@hirez.programming.kicks-ass.net> <20190502185225.0cdfc8bc@gandalf.local.home> <20190502193129.664c5b2e@gandalf.local.home> <20190502195052.0af473cf@gandalf.local.home> <20190503092959.GB2623@hirez.programming.kicks-ass.net> <20190503092247.20cc1ff0@gandalf.local.home> <2045370D-38D8-406C-9E94-C1D483E232C9@amacapital.net> <20190506081951.GJ2606@hirez.programming.kicks-ass.net> <20190506095631.6f71ad7c@gandalf.local.home> Message-ID: <20190506130643.62c35eeb@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190506170643.ipmDq8UWngWtgMcD0xunxIi9BYICs9o7Qby9x1rCeX0@z> On Mon, 6 May 2019 09:17:19 -0700 Linus Torvalds wrote: > So what is it that doesn't actually work? I've looked at the patch > even more, and I can't for the life of me see how it wouldn't work. > > Of course, I didn't test any of the actual ftrace parts, since I > short-circuited them intentionally with the above test function hack. > I have no idea what the semantics for those > ftrace_location(ip)/is_ftrace_caller(ip) cases are supposed to be, I > only tested that yes, the infrastructure clearly emulates a call > instruction. Can you try booting with: CONFIG_KPROBE_EVENTS=y CONFIG_UPROBE_EVENTS=y CONFIG_DYNAMIC_EVENTS=y CONFIG_PROBE_EVENTS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y CONFIG_FTRACE_SELFTEST=y CONFIG_FTRACE_STARTUP_TEST=y CONFIG_TRACEPOINT_BENCHMARK=y CONFIG_RING_BUFFER_BENCHMARK=y CONFIG_RING_BUFFER_STARTUP_TEST=y And see if it boots? -- Steve