[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/4] xen/arm: correctly handle an empty array of platform descs.
>>> On 14.05.13 at 12:21, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Tue, 2013-05-14 at 10:48 +0100, Jan Beulich wrote: >> >>> On 14.05.13 at 11:32, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: >> > Sadly this turns out to be a bit more complicated :-( CCing Jan and Keir >> > since this was wider implications (this construct is used elsewhere) and >> > Ian J because he pointed this out. >> > >> > TL;DR: There is probably a problem here, but I'm not sure it is one >> > worth worrying about, at least not yet/for 4.3. >> > >> > The problem is that the compiler is allowed to assume that: >> > extern const struct platform_desc _splatform[], _eplatform[]; >> > Defines two *distinct* arrays, which therefore can never be equal. Hence >> > it optimises >> > for ( platform = _splatform; platform != _eplatform; platform++ ) >> > with the assumption that there must always be at least one iteration. >> >> Did you actually observe gcc doing this? > > Yes, leading to an infinite loop. > > With my "fixed" version (with the <) it just did one needless iteration > of whatever happened to be at _splatform =_eplatform, which luckily was > accessible data. It happens to be the device data (which likely suffers > the same issue). > > I've also semi-confirmed by staring at the disassembly... Just compiled (-O2) this extern unsigned _s[], _e[]; void u(unsigned*); void test(void) { unsigned*p; for(p = _s; p != _e; ++p) u(p); } with gcc 4.7.3 for ix86, x86-64, and arm32, and none of them produced an infinite loop. And as said before, I'd be surprised a non-buggy gcc would, considering that with empty structures (which gcc allows) you can have zero-sized objects, and hence two named objects at the same address. And similarly, they support attributes to create symbol aliases, and for those it would again be necessary to account for the addresses of two distinct symbols to actually resolve to the same address. What compiler version and switches were you using for the case where you spotted bad code to be generated? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |