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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2013-05-16 at 11:17 +0100, Jan Beulich wrote:
> >>> On 15.05.13 at 15:47, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> > On Wed, 2013-05-15 at 13:19 +0100, Jan Beulich wrote:
> >> >>> On 15.05.13 at 11:47, Ian Campbell <ian.campbell@xxxxxxxxxx> 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).

On a random arm64 binary which I have here both ex_table and
ex_table.pre are empty...

> 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...

00000000 <test>:
   0:   e92d4038        push    {r3, r4, r5, lr}
   4:   e59f4020        ldr     r4, [pc, #32]   ; 2c <test+0x2c>
   8:   e59f5020        ldr     r5, [pc, #32]   ; 30 <test+0x30>
   c:   e1540005        cmp     r4, r5
  10:   28bd8038        popcs   {r3, r4, r5, pc}
  14:   e1a00004        mov     r0, r4
  18:   e2844004        add     r4, r4, #4
  1c:   ebfffffe        bl      0 <u>
  20:   e1540005        cmp     r4, r5
  24:   3afffffa        bcc     14 <test+0x14>
  28:   e8bd8038        pop     {r3, r4, r5, pc}

So indeed I think you are correct that the popcs will do the right
thing, I obviously missed the update of PC via that instruction when I
looked at this before.

> 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.

I imagine this is as much to do with the architecture ABI as the
compiler.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel