Re: [Xen-devel] stubdom vtpm build failure in staging

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/02/15 17:24, Xu, Quan wrote:
>                       
>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Xu, Quan
>> Sent: Friday, February 13, 2015 12:57 AM
>> To: Olaf Hering
>> Cc: xen-devel@xxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>>
>> Sorry for that. Read the other thread of email, it looks that some 
>> maintainers are
>> working for this issue.
>> And I am working for 'Xen stubdom vTPM for HVM virtual machine' v4 patches.
>> There are a lot of modifications.
>>
>> I will be out of office from Feb. 16th to Feb. 26th for Chinese New Year. I 
>> plan to
>> summit v4 patches Before Feb. 16, and fix this issue after Feb. 26th.
>>
>> --Quan
>>
>>
>>> -----Original Message-----
>>> From: Olaf Hering [mailto:olaf@xxxxxxxxx]
>>> Sent: Wednesday, February 11, 2015 11:21 PM
>>> To: Xu, Quan
>>> Cc: xen-devel@xxxxxxxxxxxxx
>>> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>>>
>>> On Wed, Jan 28, Xu, Quan wrote:
>>>
>>>> Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now.
>>> Any progress?
>>> These typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported
>>> compilers do not cope with current staging:
>>>
>>> # for i in `grep -w typedef stubdom/vtpmmgr/tcg.h | sed -n '/;/{s@^.*
>>> @@;s@;@@p}'` # do
>>> #         if test -n "`git grep -wn $i|grep -w typedef|grep -v
>>> stubdom/vtpmmgr/tcg.h`"
>>> #         then
>>> #                 echo $i
>>> #         fi
>>> # done
>>>
>>> BYTE
>>> BOOL
>>> UINT16
>>> UINT32
>>> UINT64
>>> TPM_HANDLE
>>> TPM_ALGORITHM_ID
>>>
>>> TPMI_RH_HIERARCHY_AUTH and TPM_ALG_ID are defined twice in the same
>>> file.
>>>
>>> This change works for me:
>>>
>>> ---
>>>  stubdom/vtpmmgr/odd_types.h  | 11 +++++++++++
>>>  stubdom/vtpmmgr/tcg.h        |  9 +--------
>>>  stubdom/vtpmmgr/tpm2_types.h | 11 +----------
>>>  3 files changed, 13 insertions(+), 18 deletions(-)  create mode
>>> 100644 stubdom/vtpmmgr/odd_types.h
>>>
>>> diff --git a/stubdom/vtpmmgr/odd_types.h b/stubdom/vtpmmgr/odd_types.h
>>> new file mode 100644 index 0000000..d72da9b
>>> --- /dev/null
>>> +++ b/stubdom/vtpmmgr/odd_types.h
>>> @@ -0,0 +1,11 @@
>>> +#ifndef VTPM_ODD_TYPES
>>> +#define VTPM_ODD_TYPES 1
>>> +typedef unsigned char BYTE;
>>> +typedef unsigned char BOOL;
>>> +typedef uint16_t UINT16;
>>> +typedef uint32_t UINT32;
>>> +typedef uint64_t UINT64;
>>> +typedef UINT32 TPM_HANDLE;
>>> +typedef UINT32 TPM_ALGORITHM_ID;
>>> +#endif
>>> +
>>> diff --git a/stubdom/vtpmmgr/tcg.h b/stubdom/vtpmmgr/tcg.h index
>>> 7321ec6..cac1bbc 100644
>>> --- a/stubdom/vtpmmgr/tcg.h
>>> +++ b/stubdom/vtpmmgr/tcg.h
>>> @@ -401,16 +401,10 @@
>>>
>>>
>>>  // *************************** TYPEDEFS
>>> ********************************* -typedef unsigned char BYTE;
>>> -typedef unsigned char BOOL; -typedef uint16_t UINT16; -typedef
>>> uint32_t UINT32; -typedef uint64_t UINT64;
>>> -
>>> +#include "odd_types.h"
> I think it is just for gcc backward compatibility. IMHO, That does seem 
> pretty strange.
> cc Daniel who is the maintainer of vTPM / XSM.
>
> -Quan

Redefining an identifier in the same scope is violation of the C spec.

Newer GCC tolerates bad code which redundantly declares identifiers, but
even newer GCC will still emit a diagnostic in -pedantic mode.

This build breakage needs fixing, and not just in the name of backwards
compatibility.

~Andrew


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel