On Saturday, May 19, 2018 9:00:08 AM CEST Pavel Machek wrote: > Hi! > > > Side note: doing some grepping, I find some other sequences that are a bit > > scary, like this: > > > > arch/x86/kernel/acpi/wakeup_32.S-.data > > arch/x86/kernel/acpi/wakeup_32.S-ALIGN > > arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_magic) .long 0 > > arch/x86/kernel/acpi/wakeup_32.S:ENTRY(saved_eip) .long 0 > > > > so apparently people are using ENTRY() for data too (the same pattern > > exists in wakeup_64.S). > > > > So we end up having those odd 0x90 bytes (now 0xcc) in the data section as > > "padding" between those two values. Crazy. > > Sorry about that. I'm pretty sure intention was simply to use the > variable from C code.. and ENTRY() worked. I was not aware that it has > side effect of padding... > > Let me see how this can be improved... (untested). > > diff --git a/arch/x86/kernel/acpi/wakeup_32.S > b/arch/x86/kernel/acpi/wakeup_32.S > index 0c26b1b..d6f477f 100644 > --- a/arch/x86/kernel/acpi/wakeup_32.S > +++ b/arch/x86/kernel/acpi/wakeup_32.S > @@ -89,8 +89,8 @@ ret_point: > > .data > ALIGN > -ENTRY(saved_magic) .long 0 > -ENTRY(saved_eip) .long 0 > +GLOBAL(saved_magic) .long 0 > +saved_eip: .long 0 > > # saved registers > saved_idt: .long 0,0
The Jiri Slaby's annotation patches touch this: https://patchwork.kernel.org/patch/10409073/ Thanks, Rafael
