> -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:[email protected]] > Sent: Tuesday, April 28, 2009 7:00 AM > To: Myles Watson > Cc: Patrick Georgi; [email protected] > Subject: Re: [coreboot] [PATCH]More consistent behaviour for printk_* > > On 27.04.2009 23:58, Myles Watson wrote: > > On Mon, Apr 27, 2009 at 3:30 PM, Carl-Daniel Hailfinger > > <[email protected]> wrote: > > > >> On 27.04.2009 20:41, Patrick Georgi wrote: > >> > >>> Am 27.04.2009 20:35, schrieb Carl-Daniel Hailfinger: > >>> > >>>> Let me propose an alternative which does not have an empty printk > call, > >>>> yet keeps the side effects of all parameters. > >>>> > >>>> Signed-off-by: Carl-Daniel Hailfinger<c- > [email protected]> > >>>> > >>>> Index: > >>>> LinuxBIOSv2- > printk_level_side_effects/src/arch/i386/lib/console_printk.c > >>>> =================================================================== > >>>> --- > >>>> LinuxBIOSv2- > printk_level_side_effects/src/arch/i386/lib/console_printk.c > >>>> (Revision 4217) > >>>> +++ > >>>> LinuxBIOSv2- > printk_level_side_effects/src/arch/i386/lib/console_printk.c > >>>> (Arbeitskopie) > >>>> @@ -13,39 +13,39 @@ > >>>> > >>>> #if MAXIMUM_CONSOLE_LOGLEVEL<= BIOS_EMERG > >>>> #undef printk_emerg > >>>> -#define printk_emerg(fmt, arg...) do {} while(0) > >>>> +#define printk_emerg(fmt, arg...) do { arg; } while(0) > >>>> > >>> ... > >>> > >>> The only gripe I have with this is that certain bugs stay uncovered > >>> (eg. the via c7 CAR thing). But granted, they're very rare (basically: > >>> when a printk_* call is in a place where function calls won't work). > >>> > >> Could you please explain? Outside ROMCC compiled code (and arguably > even > >> in ROMCC compiled code), there is not a single place where function > >> calls are allowed to fail. At least that's the impression I got in v3. > >> Since this is v2, I hope it acts sanely as well. > >> > > > > It wasn't that they were allowed to fail, it was a coding error. The > > stack wasn't set up, so the function calls failed. The problem was > > that the printk calls only failed sometimes (when they weren't > > optimized out), which is unacceptable for debugging. > > > > Thanks, it is now completely clear. > That's why the v3 qemu target has lots of stack debugging at the > beginning and end of CAR. Maybe we want to do something similar here as > well?
Good question. I think if a printk will catch it every time that seems good enough. Adding complexity adds more ways for it to break. Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
