From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 4/4] xen/arm: correctly handle an empty array of platform descs. Date: Wed, 15 May 2013 08:12:46 +0100 Message-ID: <5193518E02000078000D647F@nat28.tlf.novell.com> References: <1368462160.537.125.camel@zakaz.uk.xensource.com> <1368462182-10317-4-git-send-email-ian.campbell@citrix.com> <1368523975.14264.22.camel@zakaz.uk.xensource.com> <5192248402000078000D5E7F@nat28.tlf.novell.com> <1368526880.14264.29.camel@zakaz.uk.xensource.com> <5192666A02000078000D60F8@nat28.tlf.novell.com> <1368543272.14264.41.camel@zakaz.uk.xensource.com> <1368543416.14264.42.camel@zakaz.uk.xensource.com> <1368544071.14264.46.camel@zakaz.uk.xensource.com> <5192787B02000078000D61D3@nat28.tlf.novell.com> <1368549665.14264.60.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1368549665.14264.60.camel@zakaz.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Keir (Xen.org)" , Stefano Stabellini , Ian Jackson , "Tim (Xen.org)" , "xen-devel@lists.xen.org" , Julien Grall List-Id: xen-devel@lists.xenproject.org >>> On 14.05.13 at 18:41, Ian Campbell wrote: > On Tue, 2013-05-14 at 16:46 +0100, Jan Beulich wrote: >> >>> On 14.05.13 at 17:07, Ian Campbell wrote: >> > But if I remove only -DGCC_HAS_VISIBILITY_ATTRIBUTE the issue goes away. >> > >> > Which makes no sense because the test code has no use of that, but Aha: >> > -include >> > /local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h >> > >> > Which eventually gets us, from compiler.h: >> > #ifdef GCC_HAS_VISIBILITY_ATTRIBUTE >> > /* Results in more efficient PIC code (no indirections through GOT or PLT). > >> > */ >> > #pragma GCC visibility push(hidden) >> > #endif >> >> That's a very interesting (to me at least) side effect of applying >> hidden visibility to symbols. > > Indeed, me neither. > > I pruned all the other options and it is exactly this pragma plus -O* > which causes this behaviour, even on x86. Yes, I had double checked this too, by selectively attaching __attribute__((__visibility__())) to either or both of the involved symbols. Once present on both, any visibility other than "default" has this effect. As Linux doesn't play with symbol visibility, we're really alone having this problem, and hence indeed need to go through and audit all places where the potential for empty ranges exists. But you said "<" instead of "!=" didn't have any surprising side effects, so quite likely we won't need much code to change. Jan