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

[Alexander van Heukelum <heukelum@mailshack.com>]

On Sun, Nov 23, 2008 at 12:13:18PM -0800, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> > 
> > I put a ".p2align 5" in earlier in the series which caused the
> > apicinterrupts to be 32-byte aligned. But it is a hack, really,
> > relying on the generated code per stub to be between 17 and 32
> > bytes, on the default alignment to be 16 bytes and all stubs
> > to be in the .text section.
> > 
> > I'm in favour of aligning all of the interrupt/exception stubs
> > to 32 bytes, but it should be implemented the right way ;),
> > which means that we need KPROBE_ENTRY_P5ALIGNED and so on :-/.
> > 
> 
> I'm sorry, I really don't follow that logic at all.  Why the heck would
> KPROBE_ENTRY_P5ALIGNED be better than .p5align?

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".

> 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.

Greetings,
	Alexander

> 	-hpa