[coreboot] [PATCH]More consistent behaviour for printk_*

[Myles Watson]

> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Tuesday, April 28, 2009 7:00 AM
> To: Myles Watson
> Cc: Patrick Georgi; coreboot at coreboot.org
> 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
> > <c-d.hailfinger.devel.2006 at gmx.net> 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-
> d.hailfinger.devel.2006 at gmx.net>
> >>>>
> >>>> 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