uprobes and empty functions

[Srikar Dronamraju]

Hi David,

> I need some uprobes help.  I started working on bz640097
> (<https://bugzilla.redhat.com/show_bug.cgi?id=640097>), and hoped it was
> the same problem I was seeing with the new dtrace_vfork_exec.exp test
> (which I believe I've just fixed in uprobes2/uprobes.c).  Unfortunately,
> it wasn't the same problem.
> 
> You can use the reproducer included in that bug, or I've also attached a
> much smaller test.  Here's how to use it:
> 

I didnt get a chance today to try reproducing this. 
However I will try next week.


> Terminal 1:
> # stap -v shelly-stressor-simple.stp `which bash` `which zsh`
> 
> Terminal 2:
> # zsh -c ls
> 
> You'll get 'Segmentation fault (core dumped)'.  If you run zsh under
> gdb, you'll get:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffff7ffd020 in ?? ()
> 
> That address doesn't look valid at all.

Does this correspond to the slot address?

> 
> The simple reproducer just probes 2 functions in zsh, nohw() and
> nohwe().  In the source, both of these functions are completely empty,
> so they end up looking like:

I tried searching for nohw functions in objdump -S output but I didnt
get any hits.  However I see the following opcode under the same virtual
address and function scanhashtable I see these opcodes surrounded by a
set of nops before and some other opcodes belonging to scanhashtable
after. So I am confused how nohw/nohwe resolved to this address.

Are these opcodes part of next function/scanhashtable

> 
>    0x0000000000434ec0 <+0>:	 f3 c3	repz retq
> 

Do you see a link for vfork and these opcodes or just these opcodes
being called even in a regular traced program results in an issue?

> Josh helped me look at uprobes2/uprobes_x86.c, and it looks like repz/f3
> is in the section with the comment "opcodes we may need to refine
> support for".  It may be time for some refining...
> 
> If we're following this code correctly, check_legacy_prefix() will cause
> the repz/f3 to get skipped.  Then later in uprobe_post_ssout() there is
> a fixup for retq/c3, but there is a comment that reads:
> 
> 	 * We don't bother skipping prefixes here because none of the
> 	 * instructions that require special treatment (other than
> 	 * rip-relative instructions, handled above) involve prefixes.
> 
> Josh believes the fixup is adding correction to the ip, but it shouldn't
> because a ret already sets an ip away from the ssol area.
> 
> Do you see what is going wrong here?
> 
> Thanks for the help.
> 
> P.S.  I took a look at v11 of the new uprobes code, and didn't see
> anything substantially new in this area, so it is possible the new code
> has a similar problem.
> 

Okay, I have just run systemtap on upstream uprobes patch just once but
havent run it again since it needs utrace and my patches were lined up
on tip.  But yes the code looks similar so if its a problem here, it
could be a problem in upstream code unless there is vfork/fork element
in the picture.

I looked at your other fixes.  To me CLONE_THREAD imples CLONE_VM; Hence
we can only check for CLONE_VM.

--
Thanks and Regards
Srikar

ps:
(I am off on next Monday because of a Holiday/FTO)