Re: [Xen-devel] xen-unstable stubdom build-failure when debug=n

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-07-17 at 16:25 +0200, Sander Eikelenboom wrote:
> Thursday, July 17, 2014, 4:13:11 PM, you wrote:
> 
> 
> > On Thu, 2014-07-17 at 10:27 +0200, Sander Eikelenboom wrote:
> >> Hi,
> >> 
> >> Today i tried to do a debug=n build of xen-unstable and ran into the build 
> >> error 
> >> below.
> 
> > Yes, I see something similar:
> 
> > stubdom/../extras/mini-os/include/mini-os/tpm_tis.h: In function 
> > âtpm_tis_request_locality.part.6â:
> > tpm_tis.c:618:71: error: array subscript is below array bounds 
> > [-Werror=array-bounds]
> > cc1: all warnings being treated as errors
> 
> > Not sure why it should be debug=n only though.
> 
> > In the case I've got the code is:
> 
> >         s->loc[locty].ints &= ~(val & INTERRUPTS_SUPPORTED);
> 
> > where locty is a uint8_t, so how it can be *below* the bounds I'm not sure.
> 
> > dhcp.c:1359 in my copy (assuming it is similar to yours) is
> >     dhcp->msg_out->chaddr[i] = (i < netif->hwaddr_len) ? netif->hwaddr[i] : 
> > 0/* pad byte*/;
> > where i is a u16_t. But this is an above array bounds error, so
> > presumably the compiler thinks it knows something about the size of
> > chaddr or hwaddr vs hwaddr_len.
> 
> 
> > I'm not seeing anything in the logs for mini-os or stubdom since 4.4.0
> > which cry out to me as anything related. Except perhaps:
> 
> > commit e6e9178431725c369aeac117badc546edf18ab07
> > Author: Thomas Leonard <talex5@xxxxxxxxx>
> > Date:   Thu Jun 26 12:28:22 2014 +0100
> 
> >     mini-os: made off_t type signed
> >     
> >     POSIX requires this.
> >     
> >     Signed-off-by: Thomas Leonard <talex5@xxxxxxxxx>
> >     Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >     Acked-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> 
> > But there doesn't seem to be any size_t's involved at either site.
> 
> > *Confused*
> 
> Hrmmm i only changed 2 things that made it build .. 
> 1) debug=n to debug=y
> 2) implicit:
>         - the first build was after a "make mrproper", so that destroyed and 
> redownloaded all git sub repo stuff
>         - the second build was after a "make clean" after the first build 
> (and the change from debug=n and debug=y)
> 
> So it could also be it doesn't build on the first build due too an ordering 
> issue of something that doesn't get cleaned by a make clean ?

If that were the case then I'd expect
        git clean -ffffdqx && ./configure && make debug=n ; make debug=n
to work as well, which it doesn't seem to.

My guest is that turning off debug increases the optimisation level
which somehow makes gcc decide this code is now wrong.

Ian.



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