From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26654 invoked by alias); 25 Apr 2003 14:40:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26639 invoked from network); 25 Apr 2003 14:40:09 -0000 Received: from unknown (HELO lizzard.sbs.de) (194.138.37.39) by sources.redhat.com with SMTP; 25 Apr 2003 14:40:09 -0000 Received: from mail.fth.sbs.de (mail.fth.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.11.7/8.11.7) with ESMTP id h3PEe8S01992 for ; Fri, 25 Apr 2003 16:40:08 +0200 (MET DST) Received: from FTHW9FKA.os.fth.sbs.de (fthw9fka.os.fth.sbs.de [157.163.137.80]) by mail.fth.sbs.de (8.11.6/8.11.7) with ESMTP id h3PEe7l09895 for ; Fri, 25 Apr 2003 16:40:08 +0200 (MET DST) Received: by fthw9fka.os.fth.sbs.de with Internet Mail Service (5.5.2656.59) id ; Fri, 25 Apr 2003 16:40:07 +0200 Message-ID: <84B8B0CA0E7AC24C8EEB89B90BF8888F0190BC65@fthw9fka.os.fth.sbs.de> From: Hornung Peter To: "'gdb-patches@sources.redhat.com'" Subject: gdb 5.3 problem in ARM simulator Date: Fri, 25 Apr 2003 16:53:00 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C30B38.909824F0" X-SW-Source: 2003-04/txt/msg00491.txt.bz2 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C30B38.909824F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1061 Hi, this patch fixes a problem in the ARM simulator when executing a mode change. Please see attached emails for explanation. The bug fix skips increasing state->Reg[15] by 2 instructions during a mode change. This is the patch: --- gdb-5.3.orig/sim/arm/armemu.c 2002-07-05 16:12:01.000000000 +0200 +++ gdb-5.3/sim/arm/armemu.c 2003-04-25 16:17:19.000000000 +0200 @@ -3556,7 +3556,15 @@ check_PMUintr: state->Emulate =3D STOP; /* If we have changed mode, allow the PC to advance before stopping. */ else if (state->Emulate =3D=3D CHANGEMODE) - continue; + { + pc =3D state->Reg[15]; +#ifndef MODE32 + pc =3D pc & R15PCBITS; +#endif + state->Reg[15] =3D pc; + state->NextInstr =3D RESUME; + break; + } else if (state->Emulate !=3D RUN) break; } Regards, Peter Hornung ---------------------------------------------------------------------------- ------------- Peter Hornung, Siemens A&D PT1 D1, Siemensstra=DFe 2, 90766 F=FCrth, Germany E-Mail: Peter_Hornung@siemens.com Tel: +49-911-978-2013, Fax: +49-911-978-2035 ------_=_NextPart_000_01C30B38.909824F0 Content-Type: message/rfc822 Content-Description: gdb 5.3 problem in ARM simulator Content-length: 2531 Message-ID: <84B8B0CA0E7AC24C8EEB89B90BF8888F0190BC63@fthw9fka.os.fth.sbs.de> From: Hornung Peter To: "'nickc@redhat.com'" Subject: gdb 5.3 problem in ARM simulator Date: Fri, 25 Apr 2003 10:57:41 +0200 Return-Receipt-To: Hornung Peter MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 2063 Hi Nick, I discovered a problem in gdb 5.3 while running ARM7 code (uClinux) in the simulator. The code worked in the gdb 5.0 simulator but crashed in the 5.3 one. I attached a small trace of the executed code. The trace was done with gdb 5.0: pc: 100a9c8, instr: e95d7ffe pc: 100a9cc, instr: e1a00000 pc: 100a9d0, instr: e28dd00c pc: 100a9d4, instr: e1b0f00e (1) pc: 1411f10, instr: e3a0b000 (2) pc: 1411f14, instr: e59d0000 (3) pc: 1411f18, instr: e59d1004 pc: 1411f1c, instr: e59d2008 pc: 1411f20, instr: eb000b16 pc: 1414b80, instr: e24dd004 pc: 1414b84, instr: e3a03000 pc: 1414b88, instr: e58d3000 When I run the code in gdb 5.3, line (2) still is being traced, but not executed. Line (3) is not even traced. Until Line (1) everything is executed in the function ARMul_Emulate32. After this line a mode change is done and the following lines are executed in the function ARMul_Emulate26. You did a change a few years ago at the end of the ARMul_EmulateXX functions to stay in the function to adjust the pc in case of a mode change: if (state->Emulate =3D=3D ONCE) state->Emulate =3D STOP; /* If we have changed mode, allow the PC to advance before stopping. */ (A) else if (state->Emulate =3D=3D CHANGEMODE) (B) continue; else if (state->Emulate !=3D RUN) break; } while (!stop_simulator); =09 state->decoded =3D decoded; state->loaded =3D loaded; state->pc =3D pc; =09 return pc; } In case of a mode change state->Reg[15] is adjusted at the start of the ARMul_Emulate32 fuction by 2 instructions and ARMul_Emulate26 starts then 2 instructions too late with the execution. When I remove the lines (A) and (B), the simulator works for me, but I have no idea about the side effects of this. What is your opinion about this? Regards, Peter Hornung ---------------------------------------------------------------------------- ------------- Peter Hornung, Siemens A&D PT1 D1, Siemensstra=DFe 2, 90766 F=FCrth, Germany E-Mail: Peter_Hornung@siemens.com Tel: +49-911-978-2013, Fax: +49-911-978-2035 ------_=_NextPart_000_01C30B38.909824F0 Content-Type: message/rfc822 Content-Description: Re: gdb 5.3 problem in ARM simulator Content-length: 1802 Message-ID: From: Nick Clifton To: Hornung Peter Subject: Re: gdb 5.3 problem in ARM simulator Date: Fri, 25 Apr 2003 12:04:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-length: 1470 Hi Peter, > You did a change a few years ago at the end of the ARMul_EmulateXX > functions to stay in the function to adjust the pc in case of a mode > change: > if (state->Emulate == ONCE) > state->Emulate = STOP; > /* If we have changed mode, allow the PC to advance before > stopping. */ > (A) else if (state->Emulate == CHANGEMODE) > (B) continue; > else if (state->Emulate != RUN) > break; > } > while (!stop_simulator); > In case of a mode change state->Reg[15] is adjusted at the start of > the ARMul_Emulate32 fuction by 2 instructions and ARMul_Emulate26 > starts then 2 instructions too late with the execution. > > When I remove the lines (A) and (B), the simulator works for me, but > I have no idea about the side effects of this. > > What is your opinion about this? Hmm, to be honest I do not remember exactly why I put in this change, but I am pretty sure it was because Intel were complaining about not being able to single step through mode changes. I also think that at the time I was rather dubious of my patch, but it kept them happy, so I let it in. Since the patch obviously breaks tracing through mode changes I think that it ought to be reverted. Could you try removing it and then seeing if you can single step through the change, as well as just running normally ? If both of these work, please submit (a pre-approved) patch to the gdb mailing list to revert the change. Cheers Nick ------_=_NextPart_000_01C30B38.909824F0 Content-Type: application/octet-stream; name="ChangeLog" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ChangeLog" Content-length: 135 2003-04-25 Peter Hornung =0A= =0A= * armemu.c (ARMul_Emulate32): Fix execution of mode changes.=0A= =0A= ------_=_NextPart_000_01C30B38.909824F0--