Re: [Fwd: a small bug in the arm simulator]

Re: [Fwd: a small bug in the arm simulator]

[Nick Clifton]

Hi Jens-Christian,
 
> Some time ago I have complained, that the arm simulator does not
> know software traps.

Well it does - but not perfectly.

The reason is that the arm simulator is *not* a full arm architecture
simulator.  It is just an instruction level simulator.  It is enough
to allow the simulation of ordinary programs (that do not do complex
I/O or make use of OS services) and the test programs for gcc, g++
etc.

If you need a fully fledged, cycle accurate, architecture accurate
simulator you should consider contacting ARM for their commercial
product, or ... fixing the GNU simulator so that it is architecture
accurate.

> - 0x201aa8c <interrupt_end_os_schedule_0+12>:	 orr    r0, r0, #146
> - 0x201aa90 <interrupt_end_os_schedule_0+16>:	 msr	CPSR_fc, r0
> 
> The bug is located in 0x201aa90. It is not writing anything at all to
> the cpsr.

Are you using the latest sources from the CVS repository ?  Quite a
few bug fixes have been applied to the simulator over the last few
months, so it is possible that this might have been fixed.

If it has not been fixed, then I would suggest you try debugging the
simulator.  It is relatively straightforward.  In this case I would
suggest that you look at the code in the file sim/arm/armsupp.c which
contains most of the routines for handling state changes.

Cheers
        Nick

Re: [Fwd: a small bug in the arm simulator]

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]

Hi!

I just compiled the latest snapshot

insight+dejagnu-weekly-CVS-20010220.tar

I compiled it both for target arm-elf and pc-linux.

Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
At the moment gdb hangs when pressening the run button to start
arm-elf-gdb. This happens also for a helloWorld c-program.

The bug in the sim is still located in this snapshot.

Unfortunatly, I am to clumsy at the std. gdb console (a stable version without
insight is installed an my system) That´s why I am compiling a different gdb
frontend called "ddd" which is hopefully a little more stable. Lesstif just
compiled fine and soon ddd will be compiled too (I hope). Unfortunately I don´t
have  administrator right on my machine, that would make thinks faster.

I guess a will set a lot of breakpoints in the arm simulator code and see what
is happening.

jc

Am Fre, 23 Feb 2001 schrieben Sie:
> Hi Jens-Christian,
>  
> > Some time ago I have complained, that the arm simulator does not
> > know software traps.
> 
> Well it does - but not perfectly.
> 
> The reason is that the arm simulator is *not* a full arm architecture
> simulator.  It is just an instruction level simulator.  It is enough
> to allow the simulation of ordinary programs (that do not do complex
> I/O or make use of OS services) and the test programs for gcc, g++
> etc.
> 
> If you need a fully fledged, cycle accurate, architecture accurate
> simulator you should consider contacting ARM for their commercial
> product, or ... fixing the GNU simulator so that it is architecture
> accurate.
> 
> > - 0x201aa8c <interrupt_end_os_schedule_0+12>:         orr    r0, r0, #146
> > - 0x201aa90 <interrupt_end_os_schedule_0+16>:         msr    CPSR_fc, r0
> > 
> > The bug is located in 0x201aa90. It is not writing anything at all to
> > the cpsr.
> 
> Are you using the latest sources from the CVS repository ?  Quite a
> few bug fixes have been applied to the simulator over the last few
> months, so it is possible that this might have been fixed.
> 
> If it has not been fixed, then I would suggest you try debugging the
> simulator.  It is relatively straightforward.  In this case I would
> suggest that you look at the code in the file sim/arm/armsupp.c which
> contains most of the routines for handling state changes.
> 
> Cheers
>         Nick
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: [Fwd: a small bug in the arm simulator]

[Keith Seitz]

On Fri, 23 Feb 2001, Jens-Christian Lache wrote:

> I just compiled the latest snapshot
> insight+dejagnu-weekly-CVS-20010220.tar
> 
> I compiled it both for target arm-elf and pc-linux.
> 
> Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
> At the moment gdb hangs when pressening the run button to start
> arm-elf-gdb. This happens also for a helloWorld c-program.

Are you saying that Insight cannot even run a simple "hello world" 
program? What host?

Keith

Re: [Fwd: a small bug in the arm simulator]

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

Am Fre, 23 Feb 2001 schrieben Sie:
> On Fri, 23 Feb 2001, Jens-Christian Lache wrote:
> 
> > I just compiled the latest snapshot
> > insight+dejagnu-weekly-CVS-20010220.tar
> > 
> > I compiled it both for target arm-elf and pc-linux.
> > 
> > Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
> > At the moment gdb hangs when pressening the run button to start
> > arm-elf-gdb. This happens also for a helloWorld c-program.
> 
> Are you saying that Insight cannot even run a simple "hello world" 
> program? What host?

1.)Yes 
2.) Linux

It worked for a while...

Maybe it is getting confused by running two different gdb´s?

I have successfully compiled & installed  DDD now. Gdb runs fine in DDD.
I have set a breakpoint at ARMul_EmulateInit and I am trying to understand it.
In what variables are the values of the registers stored?

jc

> 
> Keith
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: [Fwd: a small bug in the arm simulator]

[Jens-Christian Lache]

Am Fre, 23 Feb 2001 schrieben Sie:
> On Fri, 23 Feb 2001, Jens-Christian Lache wrote:
> 
> > I just compiled the latest snapshot
> > insight+dejagnu-weekly-CVS-20010220.tar
> > 
> > I compiled it both for target arm-elf and pc-linux.
> > 
> > Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
> > At the moment gdb hangs when pressening the run button to start
> > arm-elf-gdb. This happens also for a helloWorld c-program.
> 
> Are you saying that Insight cannot even run a simple "hello world" 
> program? What host?
> 
> Keith

The problem has something to do with the .gdbtkinit file. If have installed the
last stable version from insight now (the insight front end is much better I
have to say). It works in insight now, if and only if I delete the ~/.gdbinit
file after a run of arm-elf-gdb.

jc

 -- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: [Fwd: a small bug in the arm simulator]

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

(I wish...)
-------

I think it would be nice to have swi´s working properly. I don´t know
if this really belongs to a source level simulator or not. 

Maybe it is not that much work to implement it. The different modes work
quite fine (more or less). I mentioned before that I can simulate swis and
interrupts manually. The simulator does provide the functionality already.
The steps I did to simulate a swi just have to be automated.

For hw interrupts could be applied the same. I can imagine an interrupt
button, which automatically executes the code from 0x18, set lr_irq and spsr.
That would be nice.

jc

Am Fre, 23 Feb 2001 schrieben Sie:
> Hi Jens-Christian,
> 
> > Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
> > At the moment gdb hangs when pressening the run button to start
> > arm-elf-gdb. This happens also for a helloWorld c-program.
> 
> Oh dear :-(
> 
> > The bug in the sim is still located in this snapshot.
> > 
> > Unfortunatly, I am to clumsy at the std. gdb console (a stable version without
> > insight is installed an my system) That´s why I am compiling a different gdb
> > frontend called "ddd" which is hopefully a little more stable. Lesstif just
> > compiled fine and soon ddd will be compiled too (I hope). Unfortunately I don´t
> > have  administrator right on my machine, that would make thinks faster.
> 
> May I suggest an old fashioned approach to debugging - printf
> statements.  This is how I debug the simulator.  I add in fprintf(stderr,"...
> calls at the places I am interested in, recompile GDB and then run it.
> 
> Cheers
>         Nick
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756

Re: [Fwd: a small bug in the arm simulator]

[Jens-Christian Lache]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Hello again!
(I wish...)
-------

I think it would be nice to have swi´s working properly. I don´t know
if this really belongs to a source level simulator or not. 

Maybe it is not that much work to implement it. The different modes work
quite fine (more or less). I mentioned before that I can simulate swis and
interrupts manually. The simulator does provide the functionality already.
The steps I did to simulate a swi just have to be automated.

For hw interrupts could be applied the same. I can imagine an interrupt
button, which automatically executes the code from 0x18, set lr_irq and spsr.
That would be nice.

jc

Am Fre, 23 Feb 2001 schrieben Sie:
> Hi Jens-Christian,
> 
> > Well, I could launch arm-elf-gdb from gdb, BUT just for a while.
> > At the moment gdb hangs when pressening the run button to start
> > arm-elf-gdb. This happens also for a helloWorld c-program.
> 
> Oh dear :-(
> 
> > The bug in the sim is still located in this snapshot.
> > 
> > Unfortunatly, I am to clumsy at the std. gdb console (a stable version without
> > insight is installed an my system) That´s why I am compiling a different gdb
> > frontend called "ddd" which is hopefully a little more stable. Lesstif just
> > compiled fine and soon ddd will be compiled too (I hope). Unfortunately I don´t
> > have  administrator right on my machine, that would make thinks faster.
> 
> May I suggest an old fashioned approach to debugging - printf
> statements.  This is how I debug the simulator.  I add in fprintf(stderr,"...
> calls at the places I am interested in, recompile GDB and then run it.
> 
> Cheers
>         Nick
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756