Thanks Steven for the Information.
I am surprised that even probe functions are inlined which are invoked
if there is a match of entry in the pci_id_table of that module.
I will try noinline.
On Mon, 30 Sept 2024 at 20:51, Steven Rostedt <rost...@goodmis.org> wrote:
>
> On Mon, 30 Sep 2024 18:16:01 +0530
> Maverickk 78 <maverickk1...@gmail.com> wrote:
>
> > Hello,
> >
> > I enabled ftrace and set a filter on the command line as *pcie*, I
> > dont see some of the pciehp(eg: pciehp_probe from pciehp_core.c)
> > module function calls in ftrace, It does trace pciehp_isr but nothing
> > else.
> >
> > My command line is "ftrace=function_graph ftrace_graph_filter=*pcie*
> > ", is there any restriction on tracing static function calls?
>
> Only if the compiler inlines them.
>
> Ftrace only traces true function calls. That is, locations that something
> performs a jump to via the call instruction for x86, or a branch-and-link
> for several other architectures. The function has a prologue where gcc or
> clang will insert code that will allow ftrace to attach to it.
>
> If the compiler decides to inline the function, it will no longer be
> visible to ftrace as the compiler will not add the necessary logic to allow
> ftrace to hook to it. In the binary, the function simply "disappears" and
> the content of that function is injected directly into the calling function.
>
> If you do not see the function you want listed in:
>
> /sys/kernel/tracing/available_filter_functions
>
> Then it likely was inlined by the compiler. If you don't want the compiler
> to inline your function, simply add "noinline" to that function:
>
> static noinline int foo(void)
> {
> }
>
> And that should tell gcc not to inline it.
>
> -- Steve
>
> >
> > # cat /proc/cmdline
> > BOOT_IMAGE=/boot/vmlinuz-6.11.0+
> > root=UUID=f563804b-1b93-4921-90e1-4114c8111e8f ro
> > ftrace=function_graph ftrace_graph_filter=*pcie* pciehp.pciehp_force=1
> > pciehp.pciehp_debug=1 pcie_ports=native quite splash
> > crashkernel=512M-:192M vt.handoff=7
> >
> >
> > Raghu
>
