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

["Slutz, Donald Christopher" <dslutz@xxxxxxxxxxx>]

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