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

[Carl-Daniel Hailfinger]

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?


> Hopefully that was the answer to your question.
>   

Yes, indeed.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/