Some stack trace entries for SW BP hits are not shown

[euspectre]

Fedora 25, x86_64, kernel 4.11.7-200.fc25.x86_64

The call trace entries for hello_device_write() are not always shown in the race reports from the self-tests. Example (w/o address filtering):

	[rh] Detected a data race on the the memory block at ffffffffc0cea454, size 4:
	[rh] ----- Thread 1, comm: sh ----- 
	[rh] IP: hello_plus+0x18/0x60 [test_simple]
	 save_stack_trace+0x1b/0x20
	 save_stack+0x57/0xb0 [racehound]
	 rh_do_before_insn+0x618/0x880 [racehound]
	 rh_thunk_pre+0x13/0x25 [racehound]	
// The call to hello_device_write() should be here. However, it is not shown.
	 full_proxy_write+0x54/0x90
	 __vfs_write+0x37/0x160
	 vfs_write+0xb5/0x1a0
	 SyS_write+0x55/0xc0
	 entry_SYSCALL_64_fastpath+0x1a/0xa9

	[rh] ----- Thread 2, comm: sh ----- 
	[rh] IP: right before hello_minus+0x18/0x20 [test_simple]
	 save_stack_trace+0x1b/0x20
	 save_stack+0x57/0xb0 [racehound]
	 hwbp_handler+0xde/0x100 [racehound]
	 __perf_event_overflow+0x7f/0x100
	 perf_swevent_overflow+0x9a/0xc0
	 perf_swevent_event+0x61/0x80
	 perf_bp_event+0xbe/0xd0
	 hw_breakpoint_exceptions_notify+0x11a/0x150
	 notifier_call_chain+0x4a/0x70
	 notify_die+0x45/0x60
	 do_debug+0x101/0x240
	 debug+0x35/0x70
	 hello_minus+0x18/0x20 [test_simple]
	 hello_device_write+0x3d/0x70 [test_simple]
	 full_proxy_write+0x54/0x90
	 __vfs_write+0x37/0x160
	 vfs_write+0xb5/0x1a0
	 SyS_write+0x55/0xc0
	 entry_SYSCALL_64_fastpath+0x1a/0xa9

hello_device_write() is not inline and its stack trace entry is clearly visible in the reports for another race in hello_plus():

	[rh] ----- Thread #1, comm: sh ----- 
	[rh] IP: hello_plus+0x43/0x60 [test_simple]
	<...>
	 hello_device_write+0x5b/0x70 [test_simple]
	 full_proxy_write+0x54/0x90
	 __vfs_write+0x37/0x160
	 vfs_write+0xb5/0x1a0
	 SyS_write+0x55/0xc0
	 entry_SYSCALL_64_fastpath+0x1a/0xa9

Could this be related to how the control is passed to the thunks and forward? Need to investigate.

Besides, objtool (correctly) complains when racehound.ko is built:

/build/core/thunks.o: warning: objtool: rh_thunk_pre()+0xe: call without frame pointer save/setup
/build/core/thunks.o: warning: objtool: rh_thunk_post()+0xe: call without frame pointer save/setup

The thunks, indeed, do not save the frame pointer so that it remains the same as for the original instruction. Not sure, if this is related to the problem with incomplete stack traces described above, but still.