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