[lkml]   [2018]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [lkp-robot] [x86/asm] 51bad67ffb: int3:#[##]
Side note: doing some grepping, I find some other sequences that are a bit
scary, like this:

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.

Not an actual problem, but it does show that people seem to be mis-using

There that padding is actually entirely wrong. We do *not* want to pad
between those "saved_xyz" fields. I think those should use GLOBAL too.

Or lookie here:

arch/x86/kernel/head_32.S-# boot GDT descriptor (later on used by CPU#0):
arch/x86/kernel/head_32.S- .word 0 # 32 bit
align gdt_desc.address
arch/x86/kernel/head_32.S- .word GDT_ENTRIES*8-1
arch/x86/kernel/head_32.S- .long gdt_page /*
Overwritten for secondary CPUs */

where ENTRY() will actually screw up how the code says it wants to align
the address, but now it doesn't.

I wonder if there's some way to add a test for "ENTRY only works in a code

My grep was just me doing a visual scan, I might have missed something.


 \ /
  Last update: 2018-05-16 01:06    [W:0.152 / U:2.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site