[libvirt] [PATCH 2/2] Fix build with clang

[Martin Kletzander]

On Fri, Mar 11, 2016 at 05:20:35PM +0100, Andrea Bolognani wrote:
>On Fri, 2016-03-11 at 16:36 +0100, Martin Kletzander wrote:
>> Even though this is, technically speaking, a build-breaker fix,
>> different version of this was posted before [1] and not accepted
>> (although neither rejected), so I'm sending this as another way
>> of approaching it.
>> 
>> [1] https://www.redhat.com/archives/libvir-list/2015-March/msg00203.html
>> 
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>  tests/qemuxml2argvmock.c | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>> 
>> diff --git a/tests/qemuxml2argvmock.c b/tests/qemuxml2argvmock.c
>> index 8426108b29ed..5667f34f1267 100644
>> --- a/tests/qemuxml2argvmock.c
>> +++ b/tests/qemuxml2argvmock.c
>> @@ -62,6 +62,34 @@ virNumaNodeIsAvailable(int node)
>>  {
>>      return node >= 0 && node <= virNumaGetMaxNode();
>>  }
>> +
>> +/* This is a copy-paste of the same function from src/util/virnuma.c.
>> + * the reason for this is that some compilers might inline the
>> + * function above (virNumaNodeIsAvailable) and hence mocking that
>> + * function is pointless from our test suite's POV.  This is a
>> + * (hopefully) temporary workaround until someone finds out how to
>> + * disable inlining of exported functions with -O2 on clang.  The
>> + * other option would be disabling inlining of that particular
>> + * function which was proposed but did not come to a conclusion.
>> + */
>
>I'd rather go the __attribute__((noinline)) way, because I'm very
>concerned that the two copies of virNumaNodesetIsAvailable() will
>get out of sync at some point. If that happened, our tests will
>continue to pass just fine even though the code shipped in the
>library is potentially broken.
>

I don't want this to sound like I'm against that approach.  If anyone
agrees, then let's push Jan's patch and we're good to go :)  I just
wanted to show another look at things.

>Of course if someone can come up with a proper fix, that's even
>better :)
>

That would be, but...  Anyway, thanks for your opinion, we'll see how
this goes.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160314/8b4fa013/attachment-0001.sig>