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

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

Re: Problem with DragAnObject on RISC OS 6.20

Show all headers | View raw

In message <b498a2ed-3973-49cd-b3a8-a53b6333a2eb@q2g2000vbv.googlegroups.com>
 on 28 May 2012 Gerph  wrote:

> On May 28, 8:42 am, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> > In message <6dc02b81-c9ed-4034-90d7-671f3e804...@n16g2000vbn.googlegroups.com>
> >  on 26 May 2012 Gerph  wrote:
> > > If bit 17 is clear:
> >
> > > R0-R3 are set up from the parameter block from R2.
> > > R10 contains 0 (stack limit checking may be a problem for C
> > > applications).
> > > R13 is the SVC stack
> > > You are in SVC mode.
> > > IRQ state has been preserved.
> >
> > > As you can see the sequence is very similar.
> >
> > If you have bit 17 set, we have the SVC stack limit in R10, but does that
> > make stack limit checking better for C applications, as opposed to C
> > modules? If so, I cannot see why you would want to call with bit 17
> > clear.
> 
> IIRC the stack extension check is done by checking SP-<size> < SL.
> Which cannot be the case if SL is 0. However when the static base is
> being loaded from SL-536 (or whatever the number is) that's likely to
> break if SL was 0.

Looking at what it says in PRM 5, it says bit 17 set means "SVC mode" (which
you have explained is a bit of a mistake) and also notes "use for modules,
also allows access to statics".

I wrote on 3 June 2011:

> > However, when reading PRM 5 later I noticed that it says of bit 17 "1:
> > SVC mode (use for modules; also allows access to statics)".
> >
> > My use is for a plain application, not a module.
> >
> > I take it this means that if my function (or functions it in turn calls?)
> > needs to access any static variables I will need to set this bit.

Martin Wuerthner replied:

> > No, this bit and the reference to statics is only relevant for module 
> > code. Your USR mode application will be able to access its statics in any
> > case. So, if your program is an ordinary application it should clear bit
> > 17 and set bit 18, so it really gets called back in USR mode.

So that's what I did.

Clearly this only helps for versions of the module with the RO5 fix, but it
seems from what you say later, that Martin is wrong about earlier versions of
the module.  Unless I have misunderstood either or both of you.  My brain is
definitely hurting now!

> It's not an option when I use the phrase 'NEVER' - using longjmp from
> within SVC mode to a block that has USR mode r13 will corrupt SVC_r13 and
> result in... well you can probably imagine what will happen, I'm sure. I
> doubt that this is the cause of your problems, but the point is that doing
> such an operation from there will be fatal, so you should remove all
> possible instances of it.

I did understand what "NEVER" in capitals meant!  Thanks.  I will tackle this
aspect of the code also.

> 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.

Thanks,

-- 
Matthew Phillips
Durham

Back to comp.sys.acorn.programmer | Previous | Next — Previous 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