From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH 4/4] xen/arm: correctly handle an empty
 array of platform descs.
Date: Thu, 16 May 2013 11:17:56 +0100
Message-ID: <5194CE7402000078000D6AF6@nat28.tlf.novell.com>
References: <1368462160.537.125.camel@zakaz.uk.xensource.com>
	<1368462182-10317-4-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.02.1305131748510.4799@kaball.uk.xensource.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>
	<5193518E02000078000D647F@nat28.tlf.novell.com>
	<1368611254.11138.6.camel@hastur.hellion.org.uk>
	<5193995402000078000D6733@nat28.tlf.novell.com>
	<1368625620.11138.37.camel@hastur.hellion.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1368625620.11138.37.camel@hastur.hellion.org.uk>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <ian.campbell@citrix.com>
Cc: "Keir (Xen.org)" <keir@xen.org>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim (Xen.org)" <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Julien Grall <julien.grall@citrix.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 15.05.13 at 15:47, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Wed, 2013-05-15 at 13:19 +0100, Jan Beulich wrote:
>> >>> On 15.05.13 at 11:47, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > "<" fails because it does process the (non-existent) first entry in the
>> > array. This happened to be "safe" in the case I saw but it wouldn't be
>> > in general.
>> 
>> Okay, I misread one of your earlier responses then. Did you do
>> the necessary auditing already, or should I put this on my todo
>> list?
> 
> I haven't done an audit. I put a very quicly grepped list in a previous
> mail but it is surely incomplete.

So I went through all of them - the only other ones that can be
potentially empty are .ctors and .xsm_initcalls.init (I didn't check
whether ARM has any guaranteed .ex_table.pre uses though).
Both use "<", and the compiler translates this safely on x86. My
ARM assembly skills are still lacking, but afaict the early exit being
done with "popcs" / "b.cs" should be safe too, as they cover the
"==" case (APSR.C being set for x <= y). Thus I wonder what
code you saw being generated for the "<" case...

And btw., for both 32- and 64-bit ARM, other than for x86, I see
empty structure instances occupy zero bytes (and hence distinct
symbols end up at the same address), so the compiler is conflicting
with itself here.

Jan

extern unsigned __attribute__((__visibility__("hidden"))) _s[];
extern unsigned __attribute__((__visibility__("internal"))) _e[];

struct s {} s0 = {}, s1 = {}, sa[4] = {};

void u(unsigned*);
void s(struct s*);

void test1(void) {
	unsigned*p;

	for(p = _s; p != _e; ++p)
		u(p);
}

void test2(void) {
	unsigned*p;

	for(p = _s; p < _e; ++p)
		u(p);
}

void test3(void) {
	s(&s0);
	s(&s1);
	s(sa);
	s(sa + 3);
}