Re: [PATCH 4/4] xen/arm: correctly handle an empty array of platform descs.

["Jan Beulich" <JBeulich@suse.com>]

>>> 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);
}