Re: "no match" semantic error for some existing probe points

[Roland McGrath <roland@redhat.com>]

> Is it a GCC bug? or is it the expected behavior considering GCC's
> optimizations? for ptrace_disable() is like:
> 
>      245 void ptrace_disable(struct task_struct *child)
>      246 {
>      247         /* make sure the single step bit is not set. */
>      248         clear_single_step(child);
>      249 }

It's likely you are just seeing the result of optimization.  If there is no
prologue for the function (likely), then there is no code at line 246.
clear_single_step is inlined, so there is no code at line 248 except for
what's inlined and so resolves to ptrace-common.h or to bitops.h where the
clear_tsk_thread_flag inline is defined.  

In the DWARF line information, each PC is resolved to one source location.
For inlines, this means the location of the inline's definition, and not
the source location where the inline is called.  So using only the line
info, you can't help this.

There should be a DW_TAG_inlined_subroutine containing this PC range.
That should have DW_AT_call_{file,line} attributes that say ptrace.c
line 248.  If the compiler is producing this info, then we could
potentially make systemtap use it.  The structure of DWARF information
unfortunately does not make this especially easy.


Thanks,
Roland