Messages in this thread | | | Date | Mon, 24 Nov 2008 10:07:07 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] x86: include ENTRY/END in entry handlers in entry_64.S |
| |
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
| |