We resolve actually quite a few functions to a null pc: $ stap -l 'process("/usr/bin/stap").function("*")' -vv 2>&1 | grep pc=0x0 | wc -l 1917 These null pcs get carried all the way into the stap_uprobe_specs array. It doesn't seem to have any ill effect at runtime, but it's doubtful that probes at offset 0 in a module are of any use. Depending on the root cause, we should either skip over these null addresses, or search further for what the real entrypc should be.
As an example from my pet build of stap: checking instances of inline __exchange_and_add_dispatch examining inline instance of __exchange_and_add_dispatch selected inline instance of __exchange_and_add_dispatch entry-pc lookup (dwarf_entrypc dieoffset: 0x5e0a0) = 0x0 (rc 0) [ 5e0a0] inlined_subroutine abstract_origin [ 440e8] entry_pc 000000000000000000 ranges range list [ 148c0] call_file 4 call_line 229 and up the containment hierarchy, all the way pc=0 to [ 5df50] subprogram specification [ 3cd9b] low_pc 000000000000000000 high_pc 000000000000000000 frame_base location list [ e7cd] sibling [ 5e14a] [ 5df6e] formal_parameter name "this" type [ 436c3] artificial location location list [ e87e] [ 5df7d] formal_parameter name "__x" decl_file 3 decl_line 965 type [ 3c8b4] location location list [ e8da] where 3cd9b: [ 3cd9b] subprogram external name "_M_erase" decl_file 3 decl_line 964 MIPS_linkage_name "_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE8_M_eraseEPSt13_Rb_tree_nodeISsE" accessibility private (3) declaration sibling [ 3cdba] [ 3cdae] formal_parameter type [ 3d337] artificial [ 3cdb4] formal_parameter type [ 3c8b4] % nm stap | grep [the mips-linkage-name] 000000000040ee00 W _ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE8_M_eraseEPSt13_Rb_tree_nodeISsE
commit 4ad420077