On Wed, 2015-03-25 at 17:02 +0530, Anshuman Khandual wrote:
> On 03/25/2015 10:58 AM, Michael Ellerman wrote:
> > On Wed, 2015-03-18 at 16:04 +1100, Michael Ellerman wrote:
> >> On Tue, 2015-03-17 at 11:35 +0530, Anshuman Khandual wrote:
> >>> On 03/17/2015 04:34 AM, Michael Ellerman wrote:
> >>>> What are you seeing exactly?
> >>>
> >>> I am running on a BE PKVM guest but compiling the test case on
> >>> a different BE machine which has newer version of the compiler.
> >>>
> >>> cc (GCC) 4.8.3 20140624
> >>>
> >>> cc -O2 -Wall -g -nostdlib -m64 -c -o check.o check.S
> >>> objcopy -j .text --reverse-bytes=4 -O binary check.o check-reversed.o
> >>> hexdump -v -e '/1 ".byte 0x%02X\n"' check-reversed.o > check-reversed.S
> >>> cc -O2 -Wall -g -nostdlib -m64 switch_endian_test.S check-reversed.S
> >>> -o switch_endian_test
> >>>
> >>> which looks very similar to the details you have provided above.
> >>> Running on guest or host should not make any difference.
> >>
> >> No it shouldn't.
> >>
> >> Can you try strace, that should give you the full result code.
> >>
> >> Also can you try gdb. You can't breakpoint in the wrong-endian region, but
> >> it
> >> looks like you're getting through that anyway.
> >>
> >> So try setting a breakpoint at line ~77, and you should be back in BE.
> >> Then you
> >> can single step and see where it errors out.
> >
> > Did you try these?
>
> Yeah. The test program is showing some strange behavior.
>
> (1) Without strace: It just fails with 176 return code as before
> (2) With strace: It works with return code 0 and prints everything !!
>
> strace ./switch_endian_test
> execve("./switch_endian_test", ["./switch_endian_test"], [/* 50 vars */]) = 0
> SYS_363(0x5555aaaa5555aaaa, 0x5555aaaa5555aaae, 0x5555aaaa5555aaaf,
> 0x5555aaaa5555aab0, 0x5555aaaa5555aab1) = 6149008514797120170
> write(1, "Hello wrong-endian world\n", 25Hello wrong-endian world
> ) = 25
> SYS_363(0x19, 0x10010638, 0x19, 0x5555aaaa5555aab0, 0x5555aaaa5555aab1) = 25
> write(1, "Hello right-endian world\n", 25Hello right-endian world
> ) = 25
> write(1, "success: switch_endian_test\n", 28success: switch_endian_test
> ) = 28
> exit(0) = ?
>
> With GDB and breaking at line 77, it exits with a different exit code this
> time
No that's the same code, 176 == 0260 (octal).
> 30 cmpd r3,r5
> (gdb)
> 31 bne 1f
> (gdb)
> 32 addi r3,r15,6
> (gdb)
> 33 cmpd r3,r6
> (gdb)
> 34 bne 1f
> (gdb)
> 98 1: li r0, __NR_exit
> (gdb)
> 99 sc
> (gdb)
> [Inferior 1 (process 6456) exited with code 0260]
And that makes sense, it's bailing because r6 doesn't match. In the setup we do:
addi r6, r15, 6
Where r15 is 0x5555aaaa5555aaaa, so:
0x5555aaaa5555aaaa + 6 = 0x5555aaaa5555aab0
And when we exit the kernel masks the exit code in r3 with 0xff, so:
0x5555aaaa5555aab0 & 0xff = 0xb0 = 176
So for some reason r6 does not contain our pattern.
Can you do an "info registers" and see what's in r6?
cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
