Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jens-Christian Lache <lache@tu-harburg.de>
To: gdb@sources.redhat.com
Subject: a small bug in the arm simulator
Date: Fri, 23 Feb 2001 07:50:00 -0000	[thread overview]
Message-ID: <0102231647190K.28931@lab04> (raw)

Hi everybody!

Some time ago I have complained, that the arm simulator does not know software
traps. I am able to simulate them now with the following steps:

1.) Step until the "swi" instruction, but do not execute it
(grap the register window from insight)
2.) Set mode bits in cpsr to b00011
for example 0x800000d0 -> 0x800000d3
3.) Set pc to 0x8
4.) stepi
5.) (we should now be in the swi_wrapper) set lr to the value from the swi +4
6.) if somewhere the spsr should be read into a gp reg, adjust this value to
     the old cpsr

This should work fine.

I use the same way to simlulate interrupts. If I compile my project for the
simulator, I load the address of the interrupt wrapper directly instead
obtaining it from the AIC.

It looks the following

1.) Run prog to an arbitry location and grap the reg window from insight
2.) Set mode bits in cpsr to b00010
3.) Set pc to 0x18
4.) stepi
5.) (we should now be in the tc0_interrupt_handler) set lr to the value from the
    last instruction + 4 
6.) if somewhere the spsr should be read into a gp reg, adjust this
     value to the old cpsr

This work fine so far. The assembler interrupt handler sets lr to
interrupt_end_os_schedule_0 in my case and jumps to the approriate 
C++ function. When this function is done it jumps to the value of lr. This
looks the following:

- 0x201aa80 <interrupt_end_os_schedule_0>:	 ldmia sp!, {r1, r2, r3, r12,lr} 
- 0x201aa84 <interrupt_end_os_schedule_0+4>:	 mrs	r0,CPSR 
- 0x201aa88 <interrupt_end_os_schedule_0+8>:	 bic r0,r0, #31; 0x1f 
- 0x201aa8c <interrupt_end_os_schedule_0+12>: 	 orr r0, r0, #146	; 0x92
- 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.

Can anybody explain my, how to compile gdb with debug symbols turned on?

Regards,

Jens-Christian

-- 


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


             reply	other threads:[~2001-02-23  7:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23  7:50 Jens-Christian Lache [this message]
     [not found] ` <3A9696DF.64AA0CA0@motorola.com>
2001-02-23  9:32   ` Re (2nd): " Jens-Christian Lache
2001-02-23 10:05     ` Jens-Christian Lache
2001-02-25  8:54 Jens-Christian Lache
2001-05-08  1:31 Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0102231647190K.28931@lab04 \
    --to=lache@tu-harburg.de \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox