On Fri, Oct 18, 2013 at 1:31 PM, Camm Maguire <[email protected]>wrote:
> Greetings, and thanks for your reply! I can try to get a simpler
> example, but first let me try to simplify the post, to see if that
> illumines the issue by itself. My comments after //
>
>
> Breakpoint 4, 0x00000000004c1f72 in LI46 (V457=0x60000000047b1258,
> V458=0x60000000040400e0 <Cnil_body>) at gcl_cmpfun.c:2657
> 2657 V459= (*(LnkLI268))((V458),((object)VV[165]));
> 1: x/i $pc
> => 0x4c1f72 <LI46+242>: br.call.sptk.many b0=b6;;
>
> =============================================================================
> // Here is the call to *LnkLI268
>
> =============================================================================
> (gdb) ni
> 0x00000000004c1f80 2657 V459=
> (*(LnkLI268))((V458),((object)VV[165]));
> 1: x/i $pc
> => 0x4c1f80 <LI46+256>: [MMI] mov r14=r8
>
R14 <- R8
So R14 and R8 should be the same.
> (gdb) ni
> 0x00000000004c1f81 2657 V459=
> (*(LnkLI268))((V458),((object)VV[165]));
> 1: x/i $pc
> => 0x4c1f81 <LI46+257>: mov r1=r40
> (gdb)
> 2661 {object V460 = (*(LnkLI250))((V459));
> 1: x/i $pc
> => 0x4c1f82 <LI46+258>: mov r41=r8;;
>
R41 <- R8 as well here.
So R8 == R14 == R41.
> (gdb)
> 2658 if(((V459))==Cnil){
> 1: x/i $pc
> => 0x4c1f90 <LI46+272>: [MMI] cmp.eq p6,p7=r8,r14
>
Now `cmp.eq` R8 does equal R14 here, doesn't it? This would make p6 = 1 and
p7 = 0
This clearly isn't doing the comparison you were hoping for since this is
always true.
> (gdb) i reg r14
> r14 0x6000000004af3450 6917529027719672912
> (gdb) i reg r1
> r1 0x600000000001921c 6917529027641184796
> (gdb) i reg r41
> r41 0x6000000004af3450 6917529027719672912
> (gdb) p V459
> $45 = (object) 0x6000000004af3450
>
>
> =============================================================================
> // Here is the return of 0x6000000004af3450 to V459.
> // Cnil is 0x60000000040400e0, so the comparison on 2658 should fail
>
> =============================================================================
>
> In your first message you wrote:
if(((V459))==((object)&Cnil_body)){
But here I see:
if(((V459))==Cnil){
OK, so what exactly is going on here? Is Cnil / Cnil_body a constant value
(address of a function) and V459 some function pointer variable it is being
compared against? If so, then I would say it is generating the wrong code.
Notice that:
V459 == 0x6000000004af3450 == r41 == r14 == r8
It should be loading the value of Cnil / Cnil_body (const) to do the
comparison, instead it's comparing a register against another register it
just copied from!
(gdb) ni
> 2661 {object V460 = (*(LnkLI250))((V459));
> 1: x/i $pc
> => 0x4c1f91 <LI46+273>: nop.m 0x0
> (gdb)
> 0x00000000004c1f92 2661 {object V460 =
> (*(LnkLI250))((V459));
> 1: x/i $pc
> => 0x4c1f92 <LI46+274>: addl r18=71588,r1;;
> (gdb)
> 2667 VMR46(V461)}}
> 1: x/i $pc
> => 0x4c1fa0 <LI46+288>: [MIB] (p06) st8 [r34]=r37
>
This uses p06, which is 1, so this store should happen.
> (gdb)
> 2658 if(((V459))==Cnil){
> 1: x/i $pc
> => 0x4c1fa1 <LI46+289>: nop.i 0x0
> (gdb)
> 0x00000000004c1fa2 2658 if(((V459))==Cnil){
> 1: x/i $pc
> => 0x4c1fa2 <LI46+290>: (p06) br.cond.dpnt.few 0x4c2080
> <LI46+512>;;
> (gdb)
>
> This uses p06, which is 1, so this branch is taken.
>
> =============================================================================
> // Here is the comparison that should fail, but jumps over the
> // following code instead returning V459 from the function. *LnkLI250
> is
> // never called.
>
> =============================================================================
>
> 2670 }
> 1: x/i $pc
> => 0x4c2080 <LI46+512>: [MII] nop.m 0x0
> (gdb) ni
> 0x00000000004c2081 2670 }
> 1: x/i $pc
> => 0x4c2081 <LI46+513>: mov.i ar.pfs=r39
> (gdb)
> 0x00000000004c2082 2670 }
> 1: x/i $pc
> => 0x4c2082 <LI46+514>: nop.i 0x0;;
> (gdb)
> 0x00000000004c2090 2670 }
> 1: x/i $pc
> => 0x4c2090 <LI46+528>: [MIB] nop.m 0x0
> (gdb)
> 0x00000000004c2091 2670 }
> 1: x/i $pc
> => 0x4c2091 <LI46+529>: mov b0=r38
> (gdb)
> 0x00000000004c2092 2670 }
> 1: x/i $pc
> => 0x4c2092 <LI46+530>: br.ret.sptk.many b0;;
> (gdb)
>
>
> Please let me know if this helps.
>
>
This helps to an extent, but a test case would be better. This code looks
almost machine generated (variable names/labels are mechnical-looking), and
it's hard to grasp without full context; but the disassembly is huge by
itself to just "read". I think I have made sense of it, and I think I would
agree. I bet this (and perhaps another bug, yet unknown) is the cause of
some ia64 weirdness.
> Take care,
> --
> Camm Maguire [email protected]
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
