strange things with ARMulator (thumb state, swi)

[Adrian von Bidder <avbidder at acter dot ch>]

Heyho!

We're using gdb 5.0 with patches to exactly simulate our environment
(at91, memory layout adapted). I'm still trying to get a thumb userspace
working; gcc and binutils seem to be working to the point where I can
compile simple programs (I still don't trust my gcc patch...).

Now, the problem is the thumb swi instruction - there seem to be various
problems, lr and spsr seem to have bogus values for thumb.

what I'm doing:
===
	# while executing a simple hello world
Breakpoint 1, 0x9014d526 in write ()
1: x/i $pc  0x9014d526 <write+14>:	swi	4
	# from thumb, I do syscalls by just swi <syscall-nr>
(gdb) print/x $r0
$2 = 0x1
(gdb) print/x $r1
$3 = 0x80079020
(gdb) print $r2
$3 = 15
(gdb) x/s $r1
0x80079020:	 "hello george!\n"
(gdb) print/x $cpsr
$1 = 0x30
	# registers seem to be set up right here.
	# cpsr says 'thumb state, User mode'
(gdb) break *0x8
Breakpoint 2 at 0x8
(gdb) cont
Continuing.
No mem: ARMul_readWord: @ 7261656a (kernel mode)
No mem: ARMul_readWord: @ 7261656b (kernel mode)
No mem: ARMul_readWord: @ 7261656c (kernel mode)
No mem: ARMul_readWord: @ 7261656d (kernel mode)

	# why can't I just stepi? See transcript below for what happens.
	# I don't know what he's doing here, but I arrive at the right place 
	# in the end.

Breakpoint 2, 0x8 in ?? ()
1: x/i $pc  0x8:	ldr	pc, [pc, #d8]	; 0xe8
(gdb) print/x $r0
$4 = 0x1
	# and r1, r2 keep their values, too. Nothing special here.
(gdb) print/x $lr
$6 = 0x9014d532
	# this is strange. the swi instruction is at 0x9014d526, so $lr
	# in thumb should be 0x...28. So where do these 10 bytes come from?
(gdb) print/x $cpsr
$7 = 0x9b
	# now it's 'IRQ disabled, ARM state, undefined mode' - why is it not
	# 'supervisor mode' ; 0x93?
===
When I mrs r6, spsr, r6 does *not* get the value 0x30, but seems to be
set to 0x93 instead.

Ok, enough fun here - enough that I am quite confused. I'll have to
delve in the sim source code, I fear. But if anybody has ideas about
this one, I'd be glad to hear from you.

Now, what when I stepi through the swi - strange things happen here,
too:
===
Breakpoint 1, 0x9014d526 in write ()
1: x/i $pc  0x9014d526 <write+14>:	swi	4
(gdb) stepi
0x9014d526 in write ()
1: x/i $pc  0x9014d526 <write+14>:	swi	4
	# huh? $pc not advancing?
(gdb) 
0x9014d52a in write ()
1: x/i $pc  0x9014d52a <write+18>:	cmp	r4, #0
	# cmp r4, #0 is indeed the thumb instruction at 0x...2a. But why is
	# the pc incrementing in steps of 4 now? I assume gdb thinks it's in
	# thumb state while the arm really is in ARM state.
(gdb) 
0x9014d52e in write ()
1: x/i $pc  0x9014d52e <write+22>:	
    mov	r0, r4		(add r0, r4, #0)
(gdb) 
No mem: ARMul_readWord: @ 7261656a (kernel mode)
No mem: ARMul_readWord: @ 7261656b (kernel mode)
No mem: ARMul_readWord: @ 7261656c (kernel mode)
No mem: ARMul_readWord: @ 7261656d (kernel mode)
0x4 in ?? ()
1: x/i $pc  0x4:	str	r6, [r0, -#2147]
	# and now we've had an undefined instruction - but this is strange,
	# r0 is user set up. Oh, well we shouldn't be here anyway.
===

[if stepi on a swi instruction is supposed to return only on the next
userspace instruction I'm not too worried, since the syscall decoding
may have done something strange. But I'd expect it to trace to system
mode.]
 
greets from Zürich
-- vbi