Re: [PATCH] x86: include ENTRY/END in entry handlers in entry_64.S

["H. Peter Anvin" <hpa@zytor.com>]

Alexander van Heukelum wrote:
> 
> Hello hpa,
> 
> KPROBE_ENTRY_P5ALIGNED It isn't better, that's the point.
> It's needed, because we have this problem:
> 
> 	.p2align 5
> 	KPROBE_ENTRY(something)
> 		somecode	
> 	KPROBE_END(something)
> 
> This does not align "something", because something is not in the
> same section as the ".p2align 5".
> 

I think that is braindamaged.  If KPROBE_ENTRY() changes the section
behind the programmers back, that's completely and totally stupid in an
utterly reckless sort of way.  The author of a macro like that should be
taken out and shot, because it makes the programmer think the code does
something completely different than what the code actually does.

This isn't merely ugly, it is downright dangerous.

>> For the record, I think we already have way to much macro crappage.  It
>> makes the code painful to read and hard to figure out what the real
>> constraints on it is.
> 
> I agree with that to some point. But even without the macro's, the
> code is hard to read. As an alternative to more macro's, what do you
> think of Cyrills suggestion of putting CFI-annotations next to the
> instuctions, like:
> 
> 	pushq %rax			; CFI_ADJUST_CFA_OFFSET 8
> 	movq %rax, RAX+8(%rsp)		; CFI_REL_OFFSET rax, RAX+8
> 
> instead? That still leaves the problem that the instruction and the
> annotation might not match, but it leaves the code more readable for
> someone who is used to reading x86 assembly.

I think using the macros for opcodes make sense, as the CFI operation is
tied to the operation.  That is a good way to use macros.

	-hpa