[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Fri, Jul 27, 2012 at 8:51 PM, Anthony Liguori <aliguori us ibm com> wrote:
> Blue Swirl <blauwirbel gmail com> writes:
>
>> On Fri, Jul 27, 2012 at 3:31 PM, Anthony Liguori <aliguori us ibm com> wrote:
>>> Peter Maydell <peter maydell linaro org> writes:
>>>
>>>> On 27 July 2012 15:27, Anthony Liguori <aliguori us ibm com> wrote:
>>>>> Peter Maydell <peter maydell linaro org> writes:
>>>>>> The GCC manual says "Weak symbols are supported for ELF targets,
>>>>>> and also for a.out targets when using the GNU assembler and linker".
>>>>>> Have you tested this on Windows and MacOSX ?
>>>>>
>>>>> Weak symbols are supposed to be supported by mingw32.
>>>>>
>>>>> I have no idea about MacOS X.
>>>>>
>>>>> I have no way to develop or test for MacOS X using free software so I
>>>>> honestly don't care about it.
>>>>
>>>> My approach to this is to avoid non-standard things
>>>
>>> http://en.wikipedia.org/wiki/C99#Implementations
>>>
>>> So unless you plan on compiling QEMU with xlc, pgi, or icc, I don't
>>> think relying on "standard things" really helps.
>>
>> LLVM/Clang should definitely be in the plan.
>
> weak symbols are supported by clang.
>
>>> QEMU doesn't support C99, it supports GCC.  There's no point in
>>> debating about whether we should rely on extensions or not.  We already
>>> do--extensively.
>>
>> Not so extensively. There are a few extensions for which there is no
>> simple alternative (like QEMU_PACKED) but other compilers likely need
>> similar extensions. Then there are other extensions (like :? without
>> middle expression) which can be easily avoided. We should avoid to use
>> the non-standard extensions whenever possible.
>
> I disagree.  I don't see a point to it.  QEMU has never been routinely
> built on anything other than GCC.  Why go to a lot of trouble to support
> a user base that doesn't exist?
>
> 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. There's also very little
benefit from using the nonessential extensions.

>
> 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
>>>
>>>
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]