[coreboot] [PATCH] Add the AML code generator for runtime code generation
rminnich at gmail.com
Tue Feb 3 17:40:47 CET 2009
On Tue, Feb 3, 2009 at 2:36 AM, Stefan Reinauer <stepan at coresystems.de> wrote:
> With a weak symbol, execution still has to be conditional:
> if (function_to_call)
> printk_debug("No function_to_call for this mainboard");
You're right, I did not realize this:
[rminnich at 192 tmp]$ cat weak2.c
extern unsigned long __attribute__((weak)) strong(void);
[rminnich at 192 tmp]$ cc weak2.c
[rminnich at 192 tmp]$ ./a.out
[rminnich at 192 tmp]$
I've used weak symbols for a long time but only as a way to easily
allow code to override "default" functions. This is not a usage that
would have crossed my mind. :-)
>> Weak symbols can be frustrating when you're using code management
>> tools like kscope or eclipse. You've to two symbols defined in the
>> source code base -- which do you use? (yes, I know we can tell people
>> 'just ignore the weak one' but the code analysis tools are not always
>> that smart).
> Wait. That problem is completely unrelated to weak symbols, and we will
> continue to have it, with weak symbols or without. Even more if we
> continue without weak symbols.
> The reason for that is, we call functions the same. 10 mainboards have
> write_pirq_routing_table() ... all mainboards have "main" or "amd64_main".
Ah, I can not get anyone to try make kscope eh? :-)
because if you make kscope in v3, and you look for
write_pirq_routing_table, you only see the one copy for the mainboard
you are using. I'll be doing the same for eclipse. It's a simple
trick: I use the makefile SOURCES variable to create the kscope
project file. I did this in part because I want to easily fine the
version of a function for the mainboard I am working on.
But now that I understand your point about weak symbols I guess we're
ok. I still would like, long term, to put this kind of thing into the
device operations as a phase 7.
Anyway, thanks for clearing me up on this question.
More information about the coreboot