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

[Myles Watson]

> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:[e-mail]]
> Sent: Tuesday, April 28, 2009 7:00 AM
> To: Myles Watson
> Cc: Patrick Georgi; [e-mail]
> 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
> >  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-
>
> [e-mail]>
> > > > > 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