"no match" semantic error for some existing probe points

[Gui,Jian]

> In the ptrace_disable case, a wrong pc address causes this failure:
>   dwflpp::die_has_pc (this=0x106fcdf8, die=0x10d00c94,
>                   pc=0xc000000000009e10)
> 
> But "objdump -D /boot/vmlinux-2.6.18" shows 0xc000000000009e10 is
> out of range:
> 
I think this error is due to the incomplete .debug_line information
generated by GCC.

Here is the entry of ptrace_disable in the .debug_info section of
vmlinux-2.6.18:
  <1><4670f>: Abbrev Number: 47 (DW_TAG_subprogram)
      DW_AT_sibling     : <467d3>
      DW_AT_external    : 1
      DW_AT_name        : (indirect string, offset: 0x4aa5): 
ptrace_disable
      DW_AT_decl_file   : 1
      DW_AT_decl_line   : 246
      DW_AT_prototyped  : 1
      DW_AT_low_pc      : 0x9db0
      DW_AT_high_pc     : 0x9dec
      DW_AT_frame_base  : 1 byte block: 51       (DW_OP_reg1)

But in the .debug_line section, there is no line info for
"arch/powerpc/kernel/ptrace.c:246" (see attachment).
The closest(>=246) is "arch/powerpc/kernel/ptrace.c:252", which
belongs to the next function.

When dwarf_getsrc_file() is called with lineno=246, it scans these
line info and choose "arch/powerpc/kernel/ptrace.c:252" as the best
match. The corresponding addr in the result is 0xc000000000009e10.

This addr is used to call dwarf_haspc() in dwflpp::die_has_pc, to
check whether it belongs to ptrace_disable. In dwarf_haspc():
   begin = 0xc000000000009db0,
   end   = 0xc000000000009dec,
   pc    = 0xc000000000009e10.
Here, pc addr is out of range. That's why this call failed.

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 }

Any idea? thanks.


-Guijian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug_line
URL: <http://sourceware.org/pipermail/systemtap/attachments/20061019/876e5adf/attachment.ksh>