Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.acorn.programmer > #1789
| Date | 2012-06-08 00:35 +0100 |
|---|---|
| From | Matthew Phillips <spam2011m@yahoo.co.uk> |
| Newsgroups | comp.sys.acorn.programmer |
| Subject | Re: Problem with DragAnObject on RISC OS 6.20 |
| Message-ID | <4152549c52.Matthew@sinenomine.freeserve.co.uk> (permalink) |
| References | <d3bc1c9652.Matthew@sinenomine.freeserve.co.uk> <6dc02b81-c9ed-4034-90d7-671f3e804f98@n16g2000vbn.googlegroups.com> <79bad69652.Matthew@sinenomine.freeserve.co.uk> <b498a2ed-3973-49cd-b3a8-a53b6333a2eb@q2g2000vbv.googlegroups.com> <63452a9752.Matthew@sinenomine.freeserve.co.uk> |
In message <63452a9752.Matthew@sinenomine.freeserve.co.uk>
on 28 May 2012 Matthew Phillips wrote:
> In message <b498a2ed-3973-49cd-b3a8-a53b6333a2eb@q2g2000vbv.googlegroups.com>
> on 28 May 2012 Gerph wrote:
>
> > bsearch requires a callback function, and is handled differently to other
> > calls - the size of the stack is not at issue, it is a matter of how
> > variables are referenced and the operations performed. bsearch requiring
> > the callback function means that the SCL will need to read from the
> > static base to determine what calling convention you are using. The
> > static base for the SCL is found from the stack limit - 536 (I think,
> > OTTOMH), which won't have been set up by any code, so will be invalid.
>
> [snip]
>
> > It's not just the stack size. The C environment is more than the stack
> > size - if the static base data for the C library is not correct you can
> > get yourself in a whole world of pain.
>
> And if I have understood you properly, the static base can only be found
> from the stack limit and that is only set up if bit 17 is set (whether
> DragAnObject_start was called from module code, or from application code).
>
> Is that correct?
>
> If so I definitely ought to have bit 17 set, as there are a few static
> variables being accessed from the rendering procs. It's surprising
> anything is working as well as it is on RO 4.02, 4.39, 5.16, 5.18.
I have now got a BTS dump from the user, and it says the following. I'll put
my comments before the dump, in case you don't want to scroll down.
To me it looks as though the problem comes when the Shared C Library is
trying to read from [R10,#-540] which makes sense from what you said, given
this won't have been set up. I don't know what part of the C Library is
trying to do this. It has to be pretty fundamental because my callback
function never gets called by DragAnObject_Start. I can tell this because I
modified the application to write some debug to a file at various stages, and
the line at the start of the callback function is not written to file but the
line immediately before the call to DragAnObject_Start is written. (Or,
perhaps, the debug function could be responsible for triggering the address
exception in the same way that the code did before I added the debug.)
Changing the code back so that bit 17 is set and bit 18 is clear seems to
solve the problem on RISC OS 6.20. I had better test on a few other versions
of RISC OS before I can be happy it is fixed.
I'm not totally sure about my interpretation of the dump, though, as the
value of R10 given in the register listing looks like it could have 540
deducted from it and still be in application memory, so on the face of it I
don't see a complete explanation.
It still sounds to me as though there are no disadvantages for the C
environment in having bit 17 set, so I'll stick with that if it works. I
hope this is useful to other programmers in the future puzzling over the PRM
documentation! I've certainly learned quite a lot.
The other interesting thing is that some of the other calls my application
makes to DragAnObject_Start are working fine. They have different callback
functions but go through the same Drag_Object function as the problematic
call, and were also using bit 17 clear, bit 18 set. It must have been down
to stack usage and whether statics were accessed or the calling convention
needed reading. And interesting that there were no problems on 4.02 or 4.39,
as well as the RO5 branch, of course.
Dump coming up:
Register dump:
a1/r0 =0x00000000 0
a2/r1 =0x0386e674 59172468 -> [0x00000000] [0x00000000] [0x00000000] [0x00000000]
a3/r2 =0x01c06a68 29387368 -> [0x01c06ab0] [0x01c06af4] [0x00000000] [0x7fffffff]
a4/r3 =0x03862164 59122020 -> [0xe3a00000] [0xe1b0f00e] [0x7270665f] [0x66746e69]
v1/r4 =0x01c06a6c 29387372 -> [0x01c06af4] [0x00000000] [0x7fffffff] [0x0000000a]
v2/r5 =0x01c06a68 29387368 -> [0x01c06ab0] [0x01c06af4] [0x00000000] [0x7fffffff]
v3/r6 =0x00089c9a 564378
v4/r7 =0x00000000 0
v5/r8 =0x00000073 115
v6/r9 =0x00000000 0
sl/r10=0x000a7cac "2 F1321 S81199 N"...
fp/r11=0x000a873c 689980 -> [0x2386d7d8] [0x00049c40] [0x000a3e58] [0x000126a0]
ip/r12=0x00069c40 433216 -> [0xaa000022] [0xe1a01008] [0xe1a00004] [0xebffcfd2]
sp/r13=0x000a8714
lr/r14=0x0007b0f0 504048 -> [0xe3500000] [0x159f100c] [0x18810011] [0xe2700001]
pc/r15=0x238617fb
PC disassembly from &038617a8-&038617f8:
&038617d0 : .... : e3c00003 : BIC R0,R0,#3
&038617d4 : .... : e2800004 : ADD R0,R0,#4
&038617d8 : .... : e5850000 : STR R0,[R5,#0]
&038617dc : .... : e5100004 : LDR R0,[R0,#-4]
&038617e0 : ..P. : e3500000 : CMP R0,#0
&038617e4 : ..`. : b2600000 : RSBLT R0,R0,#0
&038617e8 : .p'. : b2277001 : EORLT R7,R7,#1
&038617ec : .... : e4d68001 : LDRB R8,[R6],#1
&038617f0 : .... : ea00000c : B &03861828
&038617f4 : p... : e59f1070 : LDR R1,&0386186C
&038617f8 : .... : e51ac21c : LDR R12,[R10,#-540]
&01c068c8 (SVC) : Exception called by &03861800, CPSR SVC-26 ARM fi vCzn
{Module SharedCLibrary Code+&97FC}
Exception registers dump at &01c068dc:
a1/r0 =0x00000000 0
a2/r1 =0x0386e674 59172468 -> [0x00000000] [0x00000000] [0x00000000] [0x00000000]
a3/r2 =0x01c06a68 29387368 -> [0x01c06ab0] [0x01c06af4] [0x00000000] [0x7fffffff]
a4/r3 =0x03862164 59122020 -> [0xe3a00000] [0xe1b0f00e] [0x7270665f] [0x66746e69]
v1/r4 =0x01c06a6c 29387372 -> [0x01c06af4] [0x00000000] [0x7fffffff] [0x0000000a]
v2/r5 =0x01c06a68 29387368 -> [0x01c06ab0] [0x01c06af4] [0x00000000] [0x7fffffff]
v3/r6 =0x00089c9a 564378
v4/r7 =0x00000000 0
v5/r8 =0x00000073 115
v6/r9 =0x00000000 0
sl/r10=0x00000000 0
fp/r11=0x01c06a50 29387344 -> [0x23861707] [0x01c06a6c] [0x00089c98] [0x01c06a68]
ip/r12=0x01c06a64 29387364 -> [0x00000000] [0x01c06ab0] [0x01c06af4] [0x00000000]
sp/r13=0x01c06a08
lr/r14=0x038622d4 59122388
pc/r15=0x238617fb
PSR=0x20000003 : SVC-26 ARM fi vCzn
&01c069f4 (SVC) : Aborting called by &03861800, CPSR SVC-26 ARM fi vCzn
{Module SharedCLibrary Code+&97FC}
&01c07fc8 (SVC) : SWI &49c40 called &03c1006c {-> Module DragAnObject Code+&68}
&01c07fe0 (SVC) : SWI &69c40 called by &0386d81c {Module SharedCLibrary Code+&15818}
SWI X[DragAnObject]_0 / XDragAnObject_Start (local)
Caller disassembly from &0386d7cc-&0386d81c:
&0386d7cc : .... : e1a0c00d : MOV R12,R13
&0386d7d0 : ..-. : e92ddbf4 : STMDB R13!,{R2,R4-R9,R11,R12,R14,PC}
&0386d7d4 : ..L. : e24cb004 : SUB R11,R12,#4
&0386d7d8 : .... : e3c0c102 : BIC R12,R0,#&80000000
&0386d7dc : .... : e3100102 : TST R0,#&80000000
&0386d7e0 : .... : 038cc802 : ORREQ R12,R12,#&00020000
&0386d7e4 : ..1. : e3310000 : TEQ R1,#0
&0386d7e8 : .... : 189103ff : LDMNEIA R1,{R0-R9}
&0386d7ec : .... : 1a000009 : BNE &0386D818
&0386d7f0 : .... : e3a00000 : MOV R0,#0
&0386d7f4 : .... : e3a01000 : MOV R1,#0
&0386d7f8 : . .. : e3a02000 : MOV R2,#0
&0386d7fc : .0.. : e3a03000 : MOV R3,#0
&0386d800 : .@.. : e3a04000 : MOV R4,#0
&0386d804 : .P.. : e3a05000 : MOV R5,#0
&0386d808 : .`.. : e3a06000 : MOV R6,#0
&0386d80c : .p.. : e3a07000 : MOV R7,#0
&0386d810 : .... : e3a08000 : MOV R8,#0
&0386d814 : .... : e3a09000 : MOV R9,#0
&0386d818 : q... : ef020071 : SWI XOS_CallASWIR12
&0386d81c : .... : e59dc000 : LDR R12,[R13,#0]
Leave C-environment in USR mode: PC was &0386d81c
PC disassembly already performed
Backtrace (USR mode):
386d81c: Unnamed routine at &0386d7cc
Arg 1: 0x000a3e58 671320 -> [0x00050190] [0x000126a0] [0x000a3e80] [0x000a8770]
7b0f0: Swi
Arg 1: 0x00049c40 302144 -> [0xe5a10008] [0xe59f0000] [0xe91ba810] [0x000a2b10]
Arg 2: 0x000a3e58 671320 -> [0x00050190] [0x000126a0] [0x000a3e80] [0x000a8770]
68994: StartDragObject
68acc: Drag_Object
Arg 1: 0x000126a0 function ?
Arg 2: 0x000f1500 "Main"
Arg 3: 0x000a87d0 690128 -> [0x000003b2] [0x000003f4] [0x00000456] [0x0000042c]
Arg 4: 0x00000190 400
Arg 5: 0x00000000 0
128f8: C_DragSelection
Arg 1: 0x000f1500 "Main"
Arg 2: 0x00000001 1
16788: DragSelect
Arg 1: 0x000dd0ec 905452 -> [0x5fc23779] [0x00000000] [0x000f0c68] [0x000dd0c8]
Arg 2: 0x00000000 0
Arg 3: 0x00000040 64
69aac: CallProcs
Arg 1: 0x000dd0ec 905452 -> [0x5fc23779] [0x00000000] [0x000f0c68] [0x000dd0c8]
Arg 2: 0x00000000 0
Arg 3: 0x00000040 64
Arg 4: 0x00000040 64
69ba8: CallAllIconProcs
Arg 1: 0x000dd0ec 905452 -> [0x5fc23779] [0x00000000] [0x000f0c68] [0x000dd0c8]
Arg 2: 0x00000000 0
Arg 3: 0x00000040 64
Arg 4: 0x00000040 64
6b9ec: WIN_ProcessWindowClick
Arg 1: 0x5fc23779 1606563705
Arg 2: 0x00000000 0
Arg 3: 0x00000040 64
75e6c: MouseClick
76b9c: EV_ProcessEvent
Arg 1: 0x00000006 6
96710: IMP_ProcessEvent
Arg 1: 0x00000000 0
233c4: main
Arg 1: 0x00000002 2
Arg 2: 0x000a8e88 -> [0x000a8e9c] [0x000a8ed1] [0x00000000] [0x3c694c3e] {char**}
386b100: _main
Arg 1: 0x000a8a30 "ADFS::HardDisc4."...
Arg 2: 0x00022b34 function main
323a0: Unnamed routine at &0003236c
386b504: <root call>
--
Matthew Phillips
Durham
Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-26 22:50 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Steve Fryatt <news@stevefryatt.org.uk> - 2012-05-26 23:15 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-05-26 15:59 -0700
Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 08:42 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-05-28 12:00 -0700
Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 23:39 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-05-28 23:54 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-06-08 00:35 +0100
Re: Problem with DragAnObject on RISC OS 6.20 Gerph <gerph@gerph.org> - 2012-06-12 13:18 -0700
csiph-web