On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:
>
> On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
>> ciaran.gilles...@gmail.com> wrote:
>>
>>> I am currently investigating this unusual behavior with strcmp, and I am
>>> unable to reproduce the problem using the test_strcmp example provided.
>>>
>>> It returns the correct output of,
>>>
>>>
>>> result from strcmp('\0000','\0001' is -1)
>>>
>>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>>> 4.6.3-14 from Debian Wheezy Repo.
>>>
>>>
>> Can you set a breakpoint in strcmp and tell me what the file path is?
>> Perhaps there is a sun4v specific function (optimized version) that does
>> not have a bug?
>>
>> Patrick
>>
>>
>
> Here is the information from strcmp breakpoint
>
> ---CUT---
> Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
> (gdb) disas strcmp
> Dump of assembler code for function strcmp:
> => 0xf7ebd300 <+0>: sethi %hi(0x1010000), %g1
> 0xf7ebd304 <+4>: btst 7, %o0
> 0xf7ebd308 <+8>: bne,pn %icc, 0xf7ebd4a0 <strcmp+416>
> 0xf7ebd30c <+12>: or %g1, 0x101, %g1
> 0xf7ebd310 <+16>: andcc %o1, 7, %g3
> 0xf7ebd314 <+20>: bne,pn %icc, 0xf7ebd4e4 <strcmp+484>
> 0xf7ebd318 <+24>: sllx %g1, 0x20, %g2
> 0xf7ebd31c <+28>: ldx [ %o0 ], %o2
> ---CUT---
>
> They aren't the same implementation. Look:
or rSTR2, rSTR1, rTMP1
sethi %hi(0x80808080), r8080
andcc rTMP1, 0x7, %g0
bne,pn %icc, .Lmaybe_barrel_shift
or r8080, %lo(0x80808080), r8080
ldx [rSTR1], rWORD1
sub rSTR2, rSTR1, rSTR2
sllx r8080, 32, rTMP1
ldx [rSTR1 + rSTR2], rWORD2
or r8080, rTMP1, r8080
Side by side, the instructions aren't even the same:
Failing | Working
----------+--------
or | sethi 0x1010
sethi 8080| btst
btst* | bne
bne | or 0x101
or 808 | andcc ... %g3
ldx | bne
sub | sllx
sllx | ldx
...
*btst rA, rB -> andcc rA, rB, %g0
As far as I can tell from stepping through this it seems like a correctly
> implementation of strcmp.
>
> ---CUT---
> (gdb) info reg
> g0 0x0 0
> g1 0x20754 132948
> g2 0x33dfaf4 54393588
> g3 0x3dfaf4 4061940
> g4 0xf869cbac -127284308
> g5 0x28 40
> g6 0xfeff 65279
> g7 0xf7ff66d0 -134256944
> o0 0xffffdc48 -9144
> o1 0xffffdc50 -9136
> o2 0xffffdd34 -8908
> ---CUT---
>
> You can see that o0 and o1 are holding the pointers for the strings
> correctly and examining the value of memory at those location appears to be
> correct.
>
> With -O3 the call is the same. So I am not sure what is going on, would
> like to see an "info reg" at the breakpoint of strcmp on the affected
> systems. Also an examiniation of the memory that o0 and o1 are pointing too.
>
> -Kieron
>
>
