I am working on user space profiling based on link (https://opensource.com/article/17/7/...space#comments).

When I try to enable trace using below command, it has no effect:

root@bbr:/home/bbr/work/xxxxxxxxxx/out# echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable

root@bbr:/home/bbr/work/xxxxxxxxxx/out# cat /sys/kernel/debug/tracing/events/uprobes/enable
0

Second command should display 1.
Am I missing something? Nevertheless it should warn / throw error instead of simply having no effect.

Note: I am using Ubuntu 16.04, Kernel 4.4.x. Executed above as root only.

Thanks in advance.

Oh, sorry. I just realized it doesnt work if there is no trace point set. Not sure why it is designed so, but it seems unless there is at least 1 trace point set, it ignores the enable..

So, if I did add tracepoint before doing this by:
echo 'p:func_entry test:0x332' > /sys/kernel/debug/tracing/uprobe_events

and then enabled the probe, it worked.

And now,

After making multiple efforts, adding trace points and enabling uprobe, I couldn't see any thing in the trace file:
(Does this work only if the kernel has been built with specfic options (apart from the default enabled 'kernel debugging option'))


root@bbr:/home/bbr/xxxxxxxxxxxxxxx/out# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:2
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
root@bbr:/home/bbr/work/xxxxxxxxxxxxx/out#


Thanks in advance,

Best guess would be your offset is wrong.

Dear sysg00 thank you for the response.

The issue was actually due to not enabling /sys/kernel/debug/tracing/events/enable which is master enable. What I enabled earlier was .../events/uprobes/enable.

Regards,
Bhargav

Shouldn't matter. I ran a quick test before I replied yesterday using that test.c and enabled .../events/uprobes/enable and it all ran fine.

I don't usually use uprobes, but the entire tracing framework is a little like topsy - bits have been added over time and there are some "interesting" nuances in how different things work in practice. Guess we users just have to live with it.
Glad you got it working.

1 members found this post helpful.

Hmmm; what does this return.Adjust as necessary for the location of your config.

The command output below:

root@bbr:/home/bbr/xxxxxxxxxxxxxxx/out# grep -i [ku]probe /boot/config-$(uname -r)
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_KPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_KPROBE_EVENT=y
CONFIG_UPROBE_EVENT=y
# CONFIG_KPROBES_SANITY_TEST is not set

I tried uprobes enabling again as per your response. As you mentioned, I realized that setting '...events/uprobes/enable' to 1 is enough, without manually setting '....events/enable' to 1. The trace log is getting overwritten by latest data ('....tracing/trace'), so I could not figure out my trace point was in log, when I did in my previous post above. Any way, I can increase the buffer size or control this behaviour?

Now, another observation I did (posted just another question per this) is '..events/enable' is getting set to 'X' when I try to set it to '1' from '0'. It seems to indicate it is enabled when its value is 'X'... and not enabled indicated as '0'. Why is it 'X' instead of '1'.


Regards,
Bhargav