Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.acorn.programmer > #1789

Re: Problem with DragAnObject on RISC OS 6.20

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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