From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpaII-0001tE-VA for qemu-devel@nongnu.org; Fri, 23 Oct 2015 07:14:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpaIF-0005Zl-W4 for qemu-devel@nongnu.org; Fri, 23 Oct 2015 07:13:58 -0400 Received: from nm37-vm6.bullet.mail.ne1.yahoo.com ([98.138.229.134]:47337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpaIF-0005ZF-Ls for qemu-devel@nongnu.org; Fri, 23 Oct 2015 07:13:55 -0400 Date: Fri, 23 Oct 2015 11:11:01 +0000 (UTC) From: sridhar kulkarni Message-ID: <92821084.1995189.1445598661757.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1995188_128626130.1445598661743" Subject: Re: [Qemu-devel] qemu-system-arm system support for big endian BE8 Reply-To: sridhar kulkarni List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Paolo Bonzini , QEMU Developers , Alistair Francis ------=_Part_1995188_128626130.1445598661743 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Floating point exception error=C2=A0was the result of a divide by zero in t= he application. That is now solved and I was able to progress pretty well w= ith Big Endinan code.Currently QEMU crashes during handling interrupt contr= oller.=20 Following the dump that I captured.=20 ----------------IN: 0xe003b47c: 68e0 ldr r0, [r4, #12]0xe003b47e: b110 cbz = r0, 0xe003b486Trace 0x7f1af25f8410 [e003b47c] R00=3D00000001 R01=3D0001c200= R02=3D00000001 R03=3Dc16890e8R04=3Dc16890e8 R05=3De003b18c R06=3D00000080 = R07=3D0000a000R08=3Dffffffff R09=3D00000001 R10=3D0001c200 R11=3D00000000R1= 2=3D00000000 R13=3Dc1c3a320 R14=3De003b33d R15=3De003b47cPSR=3D20000133 --C= - T svc32----------------IN: 0xe003b486: f8d4 b01c ldr.w fp, [r4, #28]0xe00= 3b48a: f44f 5180 mov.w r1, #4096 ; 0x10000xe003b48e: f241 1021 movw r0, #43= 85 ; 0x11210xe003b492: f8ab 1000 strh.w r1, [fp]0xe003b496: f64f 4100 movw = r1, #64512 ; 0xfc000xe003b49a: f2c7 4102 movt r1, #29698 ; 0x74020xe003b49e= : 8008 strh r0, [r1, #0]0xe003b4a0: f242 1012 movw r0, #8466 ; 0x21120xe003= b4a4: 8048 strh----------------IN: 0x00000194: e121f000 msr CPSR_c, r0Trace= 0x7f1af259c000 [00000194] R00=3D8000039f R01=3D80000380 R02=3D770004c8 R03= =3D80000380R04=3D00000148 R05=3D00000000 R06=3Dc16890e8 R07=3D00000001R08= =3D00000001 R09=3D00000000 R10=3D00000000 R11=3Dc16746e1R12=3D00000000 R13= =3D00004b80 R14=3D00000188 R15=3D00000194PSR=3D80000380 N--- A usr26qemu: h= ardware error: bank number requested for bad CPSR mode value 0x0CPU #0:R00= =3D8000039f R01=3D80000380 R02=3D770004c8 R03=3D80000380R04=3D00000148 R05= =3D00000000 R06=3Dc16890e8 R07=3D00000001R08=3D00000001 R09=3D00000000 R10= =3D00000000 R11=3Dc16746e1R12=3D00000000 R13=3D00004b80 R14=3D00000188 R15= =3D00000194PSR=3D80000380 N--- A usr26s00=3D00000000 s01=3D00000000 d00=3D0= 000000000000000s02=3D00000000 s03=3D00000000 d01=3D0000000000000000s04=3D00= 000000 s05=3D00000000 d02=3D0000000000000000s06=3D00000000 s07=3D00000000 d= 03=3D0000000000000000s08=3D00000000 s09=3D00000000 d04=3D0000000000000000s1= 2=3D00000000 s13=3D00000000 d06=3D0000000000000000s14=3D00000000 s15=3D0000= 0000 d07=3D0000000000000000s16=3D00000000 s17=3D00000000 d08=3D000000000000= 0000s18=3D00000000 s19=3D00000000 d09=3D0000000000000000s20=3D00000000 s21= =3D00000000 d10=3D0000000000000000s22=3D00000000 s23=3D00000000 d11=3D00000= 00000000000s24=3D00000000 s25=3D00000000 d12=3D0000000000000000s26=3D000000= 00 s27=3D00000000 d13=3D0000000000000000s28=3D00000000 s29=3D00000000 d14= =3D0000000000000000s30=3D00000000 s31=3D00000000 d15=3D0000000000000000s32= =3D00000000 s33=3D00000000 d16=3D0000000000000000s34=3D00000000 s35=3D00000= 000 d17=3D0000000000000000s36=3D00000000 s37=3D00000000 d18=3D0000000000000= 000s38=3D00000000 s39=3D00000000 d19=3D0000000000000000s40=3D00000000 s41= =3D00000000 d20=3D0000000000000000s42=3D00000000 s43=3D00000000 d21=3D00000= 00000000000s44=3D00000000 s45=3D00000000 d22=3D0000000000000000s46=3D000000= 00 s47=3D00000000 d23=3D0000000000000000s48=3D00000000 s49=3D00000000 d24= =3D0000000000000000s50=3D00000000 s51=3D00000000 d25=3D0000000000000000s52= =3D00000000 s53=3D00000000 d26=3D0000000000000000s54=3D00000000 s55=3D00000= 000 d27=3D0000000000000000s56=3D00000000 s57=3D00000000 d28=3D0000000000000= 000s58=3D00000000 s59=3D00000000 d29=3D0000000000000000s60=3D00000000 s61= =3D00000000 d30=3D0000000000000000s62=3D00000000 s63=3D00000000 d31=3D00000= 00000000000FPSCR: 03000000Aborted (core dumped) _______________________________________________________ Please let me know if you have inputs for this crash. Also let me know if y= ou need any further info to help look in to this. RegardsSridhar=E3=80=80 =20 On Thursday, September 24, 2015 9:47 PM, Peter Crosthwaite wrote: =20 On Thu, Sep 24, 2015 at 3:48 AM, sridhar kulkarni wrote: > The issue is mostly related to my application under test. When the > application calls a function the PC is getting set up to a wrong address, > and then qemu crashes by displaying "floating point exception(core dumped= )" > message. > I am able to move ahead by resolving the issue. Was this a QEMU bug or an issue in your program? But interestingly whenever > my app crashes it always displays the same "floating point exception" > message. But I don't see any floating operations at the point code crashe= s. > I don't see any dump of the processor registers also. It's always just a = one > line message as I described above. > Ok, are you unable to share the binary or source? Alternatively, can you strip it down to a super-minimal program that replicates just this one issue? Pasting us a GDB backtrace of the failure might help as well. Regards, Peter > Regards > Sridhar > > > > On Thursday, September 24, 2015 8:23 AM, Peter Crosthwaite > wrote: > > > On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell > wrote: >> On 23 September 2015 at 03:48, sridhar kulkarni >> wrote: >>> Hi Peter, >>> >>> I was able to progress well using the BE8 work in the branch that you >>> pointed out. I am experiencing floating point issue. The qemu just exit= s, >>> by >>> putting a message that "floating point exception(core dumped)". I suppo= se >>> QEMU do support floating point operations. I heard about hard floating >>> point >>> and soft floating point support. Is there any configuration option in >>> QEMU >>> for floating point? >> >> QEMU's floating point support for ARM is good and known to work. >> If QEMU exits with a coredump then that is either: >>=C2=A0 * your test binary is dumping core due to a bug in your test >>=C2=A0 =C2=A0 (assuming you're using linux-user mode) >>=C2=A0 * a bug in QEMU (unlikely but not impossible) >> >> If you can provide a reproducible test case we can have a look at it. >> > > Yes, so the thing stopping me upstreaming this was a reasonable test. > Can I have a look at your reproducer? > > Regards, > > Peter > >> thanks >> -- PMM > > > ------=_Part_1995188_128626130.1445598661743 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=
Floating point exception error was the result = of a divide by zero in the application. That is now solved and I was able t= o progress pretty well with Big Endinan code.
Cur= rently QEMU crashes during handling interrupt controller.

Following the dump that I captured.

----------------
IN:
0xe003b47c: 68e0 l= dr=09r0, [r4, #12]
0xe003b47e: b110 c= bz=09r0, 0xe003b486
Trace 0x7f1af25f8410 [e00= 3b47c]
R00=3D00000001 R01=3D0001= c200 R02=3D00000001 R03=3Dc16890e8
R04=3Dc16890e8 R05=3De003= b18c R06=3D00000080 R07=3D0000a000
R08=3Dffffffff R09=3D0000= 0001 R10=3D0001c200 R11=3D00000000
R12=3D00000000 R13=3Dc1c3= a320 R14=3De003b33d R15=3De003b47c
PSR=3D20000133 --C- T svc= 32
----------------
IN:
0xe003b486: f8d4 b01c l= dr.w=09fp, [r4, #28]
0xe003b48a: f44f 5180 m= ov.w=09r1, #4096=09; 0x1000
0xe003b48e: f241 1021 m= ovw=09r0, #4385=09; 0x1121
0xe003b492: f8ab 1000 s= trh.w=09r1, [fp]
0xe003b496: f64f 4100 m= ovw=09r1, #64512=09; 0xfc00
0xe003b49a: f2c7 4102 m= ovt=09r1, #29698=09; 0x7402
0xe003b49e: 8008 s= trh=09r0, [r1, #0]
0xe003b4a0: f242 1012 m= ovw=09r0, #8466=09; 0x2112
0xe003b4a4: 8048 s= trh----------------
IN:
0x00000194: e121f000 = msr=09CPSR_c, r0
Trace 0x7f1af259c000 [000= 00194]
R00=3D8000039f R01=3D8000= 0380 R02=3D770004c8 R03=3D80000380
R04=3D00000148 R05=3D0000= 0000 R06=3Dc16890e8 R07=3D00000001
R08=3D00000001 R09=3D0000= 0000 R10=3D00000000 R11=3Dc16746e1
R12=3D00000000 R13=3D0000= 4b80 R14=3D00000188 R15=3D00000194
PSR=3D80000380 N--- A usr= 26
qemu: hardware error: ban= k number requested for bad CPSR mode value 0x0
CPU #0:
R00=3D8000039f R01=3D8000= 0380 R02=3D770004c8 R03=3D80000380
R04=3D00000148 R05=3D0000= 0000 R06=3Dc16890e8 R07=3D00000001
R08=3D00000001 R09=3D0000= 0000 R10=3D00000000 R11=3Dc16746e1
R12=3D00000000 R13=3D0000= 4b80 R14=3D00000188 R15=3D00000194
PSR=3D80000380 N--- A usr= 26
s00=3D00000000 s01=3D0000= 0000 d00=3D0000000000000000
s02=3D00000000 s03=3D0000= 0000 d01=3D0000000000000000
s04=3D00000000 s05=3D0000= 0000 d02=3D0000000000000000
s06=3D00000000 s07=3D0000= 0000 d03=3D0000000000000000
s08=3D00000000 s09=3D0000= 0000 d04=3D0000000000000000
s12=3D00000000 s13=3D0000= 0000 d06=3D0000000000000000
s14=3D00000000 s15=3D0000= 0000 d07=3D0000000000000000
s16=3D00000000 s17=3D0000= 0000 d08=3D0000000000000000
s18=3D00000000 s19=3D0000= 0000 d09=3D0000000000000000
s20=3D00000000 s21=3D0000= 0000 d10=3D0000000000000000
s22=3D00000000 s23=3D0000= 0000 d11=3D0000000000000000
s24=3D00000000 s25=3D0000= 0000 d12=3D0000000000000000
s26=3D00000000 s27=3D0000= 0000 d13=3D0000000000000000
s28=3D00000000 s29=3D0000= 0000 d14=3D0000000000000000
s30=3D00000000 s31=3D0000= 0000 d15=3D0000000000000000
s32=3D00000000 s33=3D0000= 0000 d16=3D0000000000000000
s34=3D00000000 s35=3D0000= 0000 d17=3D0000000000000000
s36=3D00000000 s37=3D0000= 0000 d18=3D0000000000000000
s38=3D00000000 s39=3D0000= 0000 d19=3D0000000000000000
s40=3D00000000 s41=3D0000= 0000 d20=3D0000000000000000
s42=3D00000000 s43=3D0000= 0000 d21=3D0000000000000000
s44=3D00000000 s45=3D0000= 0000 d22=3D0000000000000000
s46=3D00000000 s47=3D0000= 0000 d23=3D0000000000000000
s48=3D00000000 s49=3D0000= 0000 d24=3D0000000000000000
s50=3D00000000 s51=3D0000= 0000 d25=3D0000000000000000
s52=3D00000000 s53=3D0000= 0000 d26=3D0000000000000000
s54=3D00000000 s55=3D0000= 0000 d27=3D0000000000000000
s56=3D00000000 s57=3D0000= 0000 d28=3D0000000000000000
s58=3D00000000 s59=3D0000= 0000 d29=3D0000000000000000
s60=3D00000000 s61=3D0000= 0000 d30=3D0000000000000000
s62=3D00000000 s63=3D0000= 0000 d31=3D0000000000000000
FPSCR: 03000000
Aborted (core dumped)


_______________________________________________________

Please let me know if you hav= e inputs for this crash. Also let me know if you need any further info to h= elp look in to this.

Regards
Sridhar
=E3=80=80





On= Thursday, September 24, 2015 9:47 PM, Peter Crosthwaite <crosthwaitepet= er@gmail.com> wrote:


On Thu, Sep 24, 2015 at 3:48 AM, sridhar kulkarni
<sridhar_kulk@yahoo.com> wrote:
> The issue is mostly related to my application under test. W= hen the
> application calls a function the PC is getti= ng set up to a wrong address,
> and then qemu crashes = by displaying "floating point exception(core dumped)"
>= ; message.
> I am able to move ahead by resolving the = issue.

Was this a QEMU bug or an issue= in your program?

But interestingly wh= enever
> my app crashes it always displays the same "f= loating point exception"
> message. But I don't see an= y floating operations at the point code crashes.
> I d= on't see any dump of the processor registers also. It's always just a one> line message as I described above.
= >

Ok, are you unable to share the b= inary or source? Alternatively, can
you strip it down to = a super-minimal program that replicates just this
one iss= ue? Pasting us a GDB backtrace of the failure might help as
well.

Regards,
Pe= ter


> Regards
> Sridhar
= >
>
>
> O= n Thursday, September 24, 2015 8:23 AM, Peter Crosthwaite
> <crosthwaitepeter@gmail.com>= ; wrote:
>
>
&g= t; On Wed, Sep 23, 2015 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>> On 23 September 2015 at 03:48, sridhar kulkarni <<= a href=3D"mailto:sridhar_kulk@yahoo.com" shape=3D"rect" ymailto=3D"mailto:s= ridhar_kulk@yahoo.com">sridhar_kulk@yahoo.com>
>= ;> wrote:
>>> Hi Peter,
>= ;>>
>>> I was able to progress well using = the BE8 work in the branch that you
>>> pointed = out. I am experiencing floating point issue. The qemu just exits,
>>> by
>>> putting a message = that "floating point exception(core dumped)". I suppose
&= gt;>> QEMU do support floating point operations. I heard about hard f= loating
>>> point
>>>= and soft floating point support. Is there any configuration option in
>>> QEMU
>>> for floating= point?
>>
>> QEMU's floati= ng point support for ARM is good and known to work.
>&= gt; If QEMU exits with a coredump then that is either:
&g= t;>  * your test binary is dumping core due to a bug in your test>>    (assuming you're using linux-user mo= de)
>>  * a bug in QEMU (unlikely but not impo= ssible)
>>
>> If you can pr= ovide a reproducible test case we can have a look at it.
= >>
>
> Yes, so the thing st= opping me upstreaming this was a reasonable test.
> Ca= n I have a look at your reproducer?
>
> Regards,
>
> Peter
>
>> thanks
>>= ; -- PMM
>
>
&g= t;



=
------=_Part_1995188_128626130.1445598661743--