Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <ciaran.gillespie@gmail.com> wrote:

On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <baggett.patrick@gmail.com> wrote:

On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <ciaran.gillespie@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