Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols

[Blue Swirl]

On Fri, Jul 27, 2012 at 10:40 PM, Anthony Liguori <address@hidden> wrote:
> Blue Swirl <address@hidden> writes:
>
>> On Fri, Jul 27, 2012 at 8:51 PM, Anthony Liguori <address@hidden> wrote:
>>> If someone comes along and actively maintains support for another
>>> compiler, we can revisit.  But otherwise, there's no practical reason to
>>> avoid extensions.
>>
>> Because it's more compliant to standards.
>
> That is not a benefit.  There is no practical advantage to sticking to
> only C99.
>
> If we stuck to C99 only, QEMU would look very different.  We wouldn't
> have type_init() so we wouldn't have the module system we use today.
> It literally took me months to get those patches merged because Paul
> made exactly the same argument you're making now.
>
> And it's really been one of the better cleanups in QEMU that we've ever
> done (using modules to define devices).

Yes, it's a very nice cleanup. But I'm not saying things like that
would have to be changed much or at all. As an example for
type_init(), a script could grep and process those declarations (like
the recently posted IDL stuff) and generate type tables in a .c file
for the non-GCC compiler. Then an initialization function would just
call the functions in the table in sequence. That way GCC can use
initializers but with clever hacks, non-GCC compilers can be used too.

>
>> There's also very little benefit from using the nonessential
>> extensions.
>
> Using weak symbols eliminates #ifdefs and makes the code base a lot
> cleaner.  It makes it easier to introduce architecture specific hooks in
> a clean way.
>
> Considering how messy a lot of our target-specific code is, I think
> there could be quite a significant benefit down the road.

I don't have anything specifically against weak symbols, probably with
macros like QEMU_WEAK() they can also be accommodated later if ever
needed. Just offhand, the macro could also take a symbol prefix which
is ignored for GCC, but used in non-GCC case to create a table which a
symbol resolver (not compiled in for GCC) would use.

>
> Regards,
>
> Anthony Liguori
>
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>>>
>>>>>
>>>>>> -- if I
>>>>>> write a patch which is pretty much standard C then it's the
>>>>>> platform's problem if it mishandles it. If I write a patch
>>>>>> that uses a compiler-specific or OS-specific thing then I
>>>>>> have to also provide the relevant alternatives...so I try
>>>>>> to avoid doing that :-)
>>>>>>
>>>>>> -- PMM
>>>>>
>>>>>
>>>
>