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]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to