Re: xen-unstable stubdom build-failure when debug=n

[Sander Eikelenboom <linux@eikelenboom.it>]

Monday, July 21, 2014, 6:24:33 PM, you wrote:

> On Mon, 2014-07-21 at 17:13 +0100, Ian Campbell wrote:

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

> Well, I was right, but not how I thought...

> Turns out there are two tpm_tis.c's in our source base and I was looking
> at the wrong one ;-)

> The code in extras/mini-os/tpm_tis.c rather than
> stubdom/ioemu/hw/tpm_tis.c does look more like it might plausibly
> generate the error I'm seeing this is:

> tpm_tis.c:618:71: error: array subscript is below array bounds [-Werror=array-bounds]

> Line 618 does appear to include the use of a signed variable as an array
> offset, but I'm not sure how or why gcc is proving that it is negative.

> The code in question appears to be identical in 4.4.0 . I'm not sure
> what has changed.

> Perhaps Daniel (CCd) has some idea what is going on here.

> There's still the question of the error Sander is seeing which is
> stubdom/lwip-x86_64/src/core/dhcp.c:1359:71: error: array subscript is above array bounds [-Werror=array-bounds]

> Sander, did this used to work? If so can you identify when the
> regression occurred?

Hmm it's a pretty large window .. (essentially 4.4.0-release till now),
it was only due to Konrad's reporting of the apparent major performance regression that
ended up being a difference between debug=y and debug=n build, that made me wondering if
i would notice that effect .. so i tried a debug=n build.

If the build-test-system still has some slack, perhaps add a (weekly or only on a push) test that does a debug=n build ?
(instead of waiting for the end of the release cycle and somewhere in the RC's to fixup the things that
happen to turn up with debug=n (if my memory doesn't fail me too much, this has happened before)

(BTW i also use Debian Wheezy)
--
Sander

> Ian.