[U-Boot] [PATCH 2/2] RFC: Let linker create phy array

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 10/02/2012 21:32, Mike Frysinger a ?crit :
> On Friday 10 February 2012 14:39:12 Albert ARIBAUD wrote:
>> Le 07/02/2012 16:20, Mike Frysinger a ?crit :
>>> On Monday 06 February 2012 16:01:56 Albert ARIBAUD wrote:
>>>> Le 06/02/2012 21:57, Mike Frysinger a ?crit :
>>>>>> Is there a keep attribute like the linker has for sections?
>>>>>
>>>>> yes, __attribute__((used))
>>>>
>>>> What is the point in adding a 'static' qualifier and a ((used))
>>>> attribute, when not adding them in the first place gives the same
>>>> result?
>>>
>>> to control the visibility
>>
>> I don't understand what you mean with this. Can you please elaborate?
>
> no static means it has global elf visibility (other .c files can "extern" it,
> and you have to worry about symbol clashes):
> $ gcc -x c -c - -o test.o<<<'int foo;'&&  readelf -s test.o | grep foo
>       7: 0000000000000004     4 OBJECT  GLOBAL DEFAULT  COM foo
>
> static means it has local elf visibility (other files don't get access, and you
> don't have to worry about symbol clashes):
> $ gcc -x c -c - -o test.o<<<'static int foo;'&&  readelf -s test.o | grep foo
>       5: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    3 foo
>
> imo, anything that should not be externally accessed should have "static".
> this is just good programming practice.

I would agree 100% if the symbol was truly local, i.e. declared *and 
used* locally. Here, however, it is used globally, by being gathered in 
a global section to serve as an entry in a global array.

The only interest of making the symbol static would indeed be to allow 
reusing the symbol name elsewhere, which I think is quite improbable 
considering the symbol was global so far.

So we add the static qualifier despite the object actually not being 
static; and because the object is not actually static, that qualifier 
causes a legit diagnostic; and to eliminate that diagnostic, we add an 
'unused' attribute. This I find less than good programming practice.

> -mike

Amicalement,
-- 
Albert.