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

Myles Watson mylesgw at gmail.com
Mon Apr 27 23:58:49 CEST 2009

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 @@
>>>   #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.

Hopefully that was the answer to your question.


More information about the coreboot mailing list