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