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

Re: [Xen-devel] Compliling Xen 4.5.0 Fails with error: âbufioreq_pfnâ may be used uninitialised in this function [-Werror=uninitialized]



On 17/03/15 00:10, Slutz, Donald Christopher wrote:
> On 03/16/15 17:19, Ian Murray wrote:
>> ----- Original Message -----
>>> From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>>> To: Ian Murray <murrayie@xxxxxxxxxxx>; "xen-devel@xxxxxxxxxxxxxxxxxxx" 
>>> <xen-devel@xxxxxxxxxxxxxxxxxxx>
>>> Cc: 
>>> Sent: Monday, 16 March 2015, 9:45
>>> Subject: Re: [Xen-devel] Compliling Xen 4.5.0 Fails with error: 
>>> âbufioreq_pfnâ may be used uninitialised in this function  
>>> [-Werror=uninitialized]
>>>
>>>>  -----Original Message-----
>>>>  From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
>>>>  bounces@xxxxxxxxxxxxx] On Behalf Of Ian Murray
>>>>  Sent: 15 March 2015 22:59
>>>>  To: xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>  Subject: [Xen-devel] Compliling Xen 4.5.0 Fails with error: 
>>>> âbufioreq_pfnâ 
>>> may
>>>>  be used uninitialised in this function [-Werror=uninitialized]
>>>>
> ...
>>>>  Any suggestions are welcome,
>>>>
>>> Those line numbers don't work for me. I did a checkout of RELEASE-4.5.0 
>>> and, 
>>> whilst bufioreq_pfn is indeed declared on line 718, I see no reference to 
>>> it on 
>>> line 487. Also, if I compile debug=n I see no problem. Is it possible you 
>>> don't have a clean checkout of 4.5.0? What version of gcc are you using?
>>>
>>>   Paul
>>>
>> Thanks for replying.
>>
>> # gcc --version
>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>>
>> This is both from a brand new clone of Git and also the release
>> tarball. Ian C has commented elsewhere about what the compiler
>> might be up to, although it's beyond my knowledge in terms of
>> how "clever" the compiler is being. FWIW, I couldn't really
>> understand the line numbering, so I looked at the files
>> themselves and couldn't see a direct, either.... and surely the
>> variable in question is well out of scope at that
>> point. (obviously I am being naive about something here.)
>>
>>
>>
> The gcc I am using: gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) reported
> the same error (with adjusted line numbers) for code that I am working
> on.  The reference is really:
>
>
>
> fail3:
>     if ( !is_default && handle_bufioreq )
>         hvm_free_ioreq_gmfn(d, bufioreq_pfn);
>
>
> So I had assumed that I had uncovered a gcc bug, since the only path
> here to "hvm_free_ioreq_gmfn(d, bufioreq_pfn)" requires
> "handle_bufioreq" to be true and not the goto for fail2.  It looks to me
> like  bufioreq_pfn is always set if you get to fail3's call on
> "hvm_free_ioreq_gmfn". This report looks to same to me.  I am not able
> to see your issue, but I am planning on including:
>
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 72be5b9..cb6c763 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -715,7 +715,7 @@ static int hvm_ioreq_server_map_pages(struct
> hvm_ioreq_server *s,
>                                        bool_t is_default, bool_t
> handle_bufioreq)
>  {
>      struct domain *d = s->domain;
> -    unsigned long ioreq_pfn, bufioreq_pfn;
> +    unsigned long ioreq_pfn, bufioreq_pfn = 0;
>      int rc;
>
>      if ( is_default )
>
>
> Which "fixed" it for me.  It would be good for you to try this.
>
>    -Don Slutz

Thanks for reply. Elsewhere Ian Campbell got to the same conclusion
regarding the real "issue" being around fail3. I tried zeroing the
variable earlier tonight... as much to test to see if there were further
issues down the line as anything. Xen compiled without error. Thanks again.




>>
>>   
>>>>  Thanks for reading,
>>>>
>>>>  Ian.
>>>>
>>>>  _______________________________________________
>>>>  Xen-devel mailing list
>>>>  Xen-devel@xxxxxxxxxxxxx
>>>>  http://lists.xen.org/xen-devel
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxx
>>> http://lists.xen.org/xen-devel
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.