This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]