Re: [lttng-dev] Capturing User-Level Function Calls/Returns

2020-07-15 Thread Steven Rostedt via lttng-dev
On Wed, 15 Jul 2020 20:37:16 +0430 ahmadkhorrami wrote: > Hi, > What is the most efficient way to capture occurrence of a function > call/return of a binary program in userspace? > It seems the answer is Uprobes. 1) Am I right? > But Uprobes use "int" instruction which leads to a switch into ker

Re: [lttng-dev] Capturing User-Level Function Calls/Returns

2020-07-15 Thread Mathieu Desnoyers via lttng-dev
- On Jul 15, 2020, at 2:28 PM, rostedt rost...@goodmis.org wrote: > On Wed, 15 Jul 2020 20:37:16 +0430 > ahmadkhorrami wrote: > >> Hi, >> What is the most efficient way to capture occurrence of a function >> call/return of a binary program in userspace? >> It seems the answer is Uprobes. 1)

Re: [lttng-dev] Capturing User-Level Function Calls/Returns

2020-07-15 Thread Steven Rostedt via lttng-dev
On Thu, 16 Jul 2020 02:09:50 +0430 ahmadkhorrami wrote: > Hi Steven and Mathieu, > Firstly, many thanks! This method seems to be the most efficient method. > But, IIUC, what you suggest requires source code compilation. I need an > efficient dynamic method that, given the function address, capt

Re: [lttng-dev] Capturing User-Level Function Calls/Returns

2020-07-15 Thread Michel Dagenais via lttng-dev
> Without recompiling, how would that be implemented? As you mentioned, this is possible when "jump patching" 5 bytes instructions. Fast tracepoints in GDB and in kprobe do it. Kprobe goes further and patches sequences of instructions (because the target instruction is less than 5 bytes) if t

Re: [lttng-dev] Capturing User-Level Function Calls/Returns

2020-07-15 Thread Frank Ch. Eigler via lttng-dev
Hi - > If you can afford a more invasive tool, that requires a lot of > memory and stops your application for quite some time, you can look > at approaches like dyninst that decompile the binary, insert > instrumentation code and reassemble the code. > https://dyninst.org/ For the record, system