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

Jens-Christian Lache
2001-02-23T11:38:00Z

[-- 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