[PATCH v3 2/2] selftests/powerpc: Add a test of the switch_endian() syscall
Anshuman Khandual
khandual at linux.vnet.ibm.com
Thu Mar 26 17:24:34 AEDT 2015
On 03/26/2015 06:06 AM, Michael Ellerman wrote:
> 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?
Sure, here are the details.
(gdb)
98 1: li r0, __NR_exit
(gdb)
99 sc
(gdb) info registers
r0 0x1 1
r1 0x3ffffffff360 70368744174432
r2 0x10018670 268535408
r3 0x5555aaaa5555aab0 6149008514797120176
r4 0x5555aaaa5555aaca 6149008514797120202
r5 0x5555aaaa5555aaaf 6149008514797120175
r6 0x4000 16384 <<=========================
r7 0x100002e4 268436196
r8 0x800000010000d033 9223372041149796403
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
r13 0x5555aaaa5555aab7 6149008514797120183
r14 0x1001061a 268502554
r15 0x5555aaaa5555aaaa 6149008514797120170
r16 0x5555aaaa5555aaba 6149008514797120186
r17 0x5555aaaa5555aabb 6149008514797120187
r18 0x5555aaaa5555aabc 6149008514797120188
r19 0x5555aaaa5555aabd 6149008514797120189
r20 0x5555aaaa5555aabe 6149008514797120190
r21 0x5555aaaa5555aabf 6149008514797120191
r22 0x5555aaaa5555aac0 6149008514797120192
r23 0x5555aaaa5555aac1 6149008514797120193
r24 0x5555aaaa5555aac2 6149008514797120194
r25 0x5555aaaa5555aac3 6149008514797120195
r26 0x5555aaaa5555aac4 6149008514797120196
r27 0x5555aaaa5555aac5 6149008514797120197
r28 0x5555aaaa5555aac6 6149008514797120198
r29 0x5555aaaa5555aac7 6149008514797120199
r30 0x5555aaaa5555aac8 6149008514797120200
r31 0x5555aaaa5555aac9 6149008514797120201
pc 0x10000468 0x10000468 <._start+856>
msr 0x800000014000d032 9223372042223538226
cr 0x40fff000 1090514944
lr 0x5555aaaa5555aaca 0x5555aaaa5555aaca
ctr 0x0 0
xer 0x0 0
orig_r3 0xc000000000009974 -4611686018427348620
trap 0xd00 3328
(gdb) s
[Inferior 1 (process 8377) exited with code 0260]
More information about the Linuxppc-dev
mailing list