http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #15 from Markus Trippelsdorf <trippels at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #14) > (In reply to Markus Trippelsdorf from comment #13) > > > It is undestandable the patch changes how most/all stdarg functions are > > > compiled in the kernel, the question is why the kernel cares in certain > > > cases. Do you get some OOPS in the utxferror case or also silent hang > > > without being able to tell what is going on? In ACPI case, I'd guess if > > > the > > > routine calls into BIOS that the BIOS (or whatever qemu uses instead of > > > BIOS) might assume 16-byte stack alignment which is part of the ABI, but > > > the > > > kernel intentionally only guarantees 8-byte stack alignment. > > > > It's also a silent hang in the utxferror case. In both cases the kernel > > just executes the halt loop in early_idt_handler: > > 0xffffffff81a81165 <+69>: hlt > > => 0xffffffff81a81166 <+70>: jmp 0xffffffff81a81165 > > <early_idt_handler+69> > > I've been out of the kernel business for 13+ years or so, so don't remember > details, looking at head_64.S I wonder if you couldn't try to enable > CONFIG_EARLY_PRINTK and see if you get some better diagnostics. Yeah, I've already tried this, but it doesn't produce any diagnostic at all.
