[coreboot] [PATCH] v3: introduce generic global variable storage

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun Aug 10 14:03:22 CEST 2008

Hi Segher,

can you answer the question near the end of this mail with your gcc hat
on? Thanks.

On 10.08.2008 03:49, ron minnich wrote:
> On Sat, Aug 9, 2008 at 5:45 PM, Carl-Daniel Hailfinger wrote:
>> +struct global_vars {
>> +       struct printk_buffer *printk_buffer;
>> +#endif
>> +};
> I think you should always leave the struct the same size and let it
> have struct members that are in some cases unused.

If we do that, we also have to keep the definition of struct
printk_buffer outside #ifdef CONFIG_CONSOLE_BUFFER and that is not
really clean. But I see your point there.

> Why not have, e.g,  a page sized global area and allocate out of it?

Please NO! One page (4k) is really beyond what we need and with a
minimum CAR size of 4k, we will have exactly zero stack left for
function calls.

> Hmm. we just recreated malloc.

You're free to use malloc in stage2 and beyond, but please keep that
complexity out of stage1. malloc becomes ugly really fast if it can fail
easily due to size constraints.

> hmm. Why not when we allocate stack have a constant that defines a
> 'base of stack' area that is some fixed size, which matches struct
> global_vars in size? just random thoughts.

I could move the area allocation to be local to stage1_main. That makes
some code more complicated, but individual stage0 asm files can be left
alone when changing the global var struct.
However I'd like a compiler expert to tell me that gcc will NEVER
optimize away or reuse that stack allocation (local variable
"global_buffer") even if that variable is completely unused in the
respective function.

int stage1_main()
	char global_buffer[1234];
	return 0;

> This is close but Peter's comment is important.

I'll push my explanation from my mail answering him into the code.



More information about the coreboot mailing list