* Re: a small bug in the arm simulator
@ 2001-05-08 1:31 Nick Clifton
0 siblings, 0 replies; 3+ messages in thread
From: Nick Clifton @ 2001-05-08 1:31 UTC (permalink / raw)
To: lache, gdb; +Cc: fnasser
Hi Jens-Christian,
Thanks for finding the bug and submitting the patch. I have applied
it to the sources. In the future if you have other problems with
the simulator, you might also like to copy the bug report to the
binutils mailing list <binutils@sources.redhat.com>, which also has
an interest in this tool.
Cheers
Nick
^ permalink raw reply [flat|nested] 3+ messages in thread* a small bug in the arm simulator
@ 2001-02-25 8:54 Jens-Christian Lache
0 siblings, 0 replies; 3+ messages in thread
From: Jens-Christian Lache @ 2001-02-25 8:54 UTC (permalink / raw)
To: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]
Hi!
First of all: Thank you a lot for having fixed the "swi" instruction! No
more "unknown swi xxx". I have stepped through all the code from my
swi_wrapper and swi_handler and it worked very nice! :-) :-)
I think, I have found the little bug in the arm simulator.
It is only one line in "armsupp.c", function ARMul_FicCPSR:
void
ARMul_FixCPSR (ARMul_State * state, ARMword instr, ARMword rhs)
{
state->Cpsr = ARMul_GetCPSR (state);
/* original src */
/* if (state->Bank != USERBANK) */ // buggy
/* end original src */
/* altered src */
if (state->Mode != USER32MODE)
/* end altered src */
{ /* In user mode, only write flags */
if (BIT (16))
SETPSR_C (state->Cpsr, rhs);
if (BIT (17))
SETPSR_X (state->Cpsr, rhs);
if (BIT (18))
SETPSR_S (state->Cpsr, rhs);
}
if (BIT (19))
SETPSR_F (state->Cpsr, rhs);
ARMul_CPSRAltered (state);
}
The original version tried to determine the cpu state by the banked
registers. This works most time, but not if we are in system mode. System and
user mode have same banked registers. That why
msr cpsr, r0
worked for all modes but not for system mode.
I don´t know, how to care about the case we are in USER26MODE, it could be
done with some "defines" I would suppose.
I hope this little fix does not have any side effects!
Regards,
Jens-Christian
--
Jens-Christian Lache
www.tu-harburg.de/~sejl1601
lache@tu-harburg.de
Tel.: 01759610756 (Hamburg)
^ permalink raw reply [flat|nested] 3+ messages in thread* a small bug in the arm simulator
@ 2001-02-23 7:50 Jens-Christian Lache
0 siblings, 0 replies; 3+ messages in thread
From: Jens-Christian Lache @ 2001-02-23 7:50 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-05-08 1:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-08 1:31 a small bug in the arm simulator Nick Clifton
-- strict thread matches above, loose matches on Subject: below --
2001-02-25 8:54 Jens-Christian Lache
2001-02-23 7:50 Jens-Christian Lache
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox