Forum > Operating Systems

Lazarus for RISC OS

<< < (35/37) > >>

micken:
BAH!

I tried now setting breakpoints around the call to SysOSAlloc.. rtl/inc/heap.inc
Can't really get that working. I can set a breakpoint in SysOSAlloc, right after my allocator returns.. no bad pointers (yet).

(re-enabled the first of crash)
Code looks like:

--- Code: ---  if pmc_next<>nil then
   31cb8:       e3520000        cmp     r2, #0
        pmc_next^.prev_fixed := pmc;
   31cbc:       15820008        strne   r0, [r2, #8]

--- End code ---

R2 is #0 every time until crash where it is a bad pointer. All calls to SysOSAlloc gives valid ram.
R0 points to pmc and is a address from allocator..

Checking for #0 doesn't catch everything.


--- Code: ---pmc_next := loc_freelists^.fixedlists[chunkindex];
   31ca4:       e7942105        ldr     r2, [r4, r5, lsl #2]
      pmc^.next_fixed := pmc_next;
   31ca8:       e5802004        str     r2, [r0, #4]

--- End code ---

More fun! It is freelists that is empty (probably).  pmc_next is set to 0x0 ( as can be seen above)
The next store works because pmc is allocated right before.

micken:
Hmm.

If I move to next part after the crashing one it looks like this:

--- Code: --- loc_freelists^.fixedlists[chunkindex] := pmemchunk_fixed(result);
   31cb4:       e7846105        str     r6, [r4, r5, lsl #2]

--- End code ---
and before

--- Code: ---pmc_next := loc_freelists^.fixedlists[chunkindex];
   31ca4:       e7942105        ldr     r2, [r4, r5, lsl #2]

--- End code ---

Very interesting is that the store to loc_freelist (r4) with index (r5) always contains a valid address in r6.
But when loading back r2 is 0x0 most of the time. When it crash index is 7 which has been set to valid address previously.

This is how it looks like when it stores to index 7

--- Code: ---Register dump (stored at &2000D5D0) is:
R0  = 21F34F6C R1  = 00007F90 R2  = 00000000 R3  = 00000071
R4  = 0045B5D4 R5  = 00000007 R6  = 21F2D01C R7  = 00100000
R8  = 21F2D000 R9  = 00000070 R10 = 00000001 R11 = 00927F44
R12 = 00007FDC R13 = 00927E70 R14 = 000369BC R15 = 00031CB4
Mode USR32 flags set: nZCvqjggggeaift        PSR = 60000010

--- End code ---
As you can see R6 is a valid address. So.. what on earth happens??
If this didn't work on all existent platforms I would have guessed a variable overflow. If this is the case now on riscos I would call it a bug, but please educate me.

StefanRISCOS:

--- Quote from: micken on August 15, 2023, 07:34:41 am ---
--- Quote ---Something like that is available in rtl/linux/arm/syscall.inc named FpSysCall (with overloads for different parameters, and using nostackframe). If possible it would be better to re-use those for consistency. Also note the call to seterrno which sets a systemwide error number.
--- End quote ---

As far as I can see Linux syscalls doesn't return information in a lot of registers.. which is the case for many swi's on riscos. You also need to know that riscos swi is called with swi #number and number is unique for every call. _kernel_swi works like the above ( the last example ). You pass a pointer to register arrays ( probably can be be done with records). and at the end writes back the registers. Also note the self modifying part. Somehow the swi number needs to be passed in. It isn't in a register it is just in the same word as the instruction ( simplified ). So again different than the linux way , where it just calls swi #0 with syscall number in regs.

--- End quote ---

Not sure if the SWI call stuff is solved already between you but I agree with Micken that should have a general RISCOS_SWI() function.
That can be called and returns all necessary results.

As background info:
The RISC OS SWI (Software Interrupt) calls have not only a number but also a text definition but I am not sure how that will be initialized in Pascal.
There should be in general a definition or include of this names or simply on top of RISCOS_SWI.pas inside which also the RISCOS_SWI() function is included.
The full list is here.
List of SWI calls: http://www.riscos.com/support/developers/prm_index/numswilist.html

For my taste it is better to use the text than just the number for readablilty of the code.
example in BASIC with inline ARM assembler:
OS_WriteI = &100
...
[
...
SWI OS_WriteI+ASC">"
...]

So in Pascal will be like:
$error = RISCOS_SWI("OS_WriteI",">");

Info about register use in RISC OS SWI calls and ARM assembler : http://www.riscos.com/support/developers/prm/asm.html

StefanRISCOS:
Is there any diagram which shows the functional parts of FPC and another from Lazarus?
In addition which folders belong to which parts of that diagram.
If not would be nice if anyone can do it.

For the Lazarus IDE is there a part that is used to implement the graphical user interface and another one for the widget support?
Question to Micken: Should we use the toolbox or a lower level implementation?
The Lazarus widgets are basically an extented version of the RISC OS toolbox as it includes also more powerful widgets like database access etc. The Lazarus "Toolbox" should use the standard RISC OS files like res (Resource) files (Window, bar and menu definitions) and sprites (for icons and images).

Or that will be a problem with compatibility of porting non-RISC OS Lazarus programs to RISC OS?
Maybe a converter tool can help here. What are the policies of Lazarus here?

TRon:

--- Quote from: StefanRISCOS on August 20, 2023, 07:45:18 pm ---Not sure if the SWI call stuff is solved already between you but I agree with Micken that should have a general RISCOS_SWI() function.
That can be called and returns all necessary results.

--- End quote ---
There is nothing that needs to be solved, firstly because not implemented yet but more important you can go either way as well as implement/support both scenarios.

I personally disagree for using a common SWI implementation (based upon what I've read so far) because it is unworkable for end-users to know the input and/or output for all the different SWI function calls (even though it is documented). But, for someone being experienced with assembler calls like that it should not be a problem and you probably expect for all CPU registers to return their value just as you would probably like to have full control over setting the content of those registers as well.

Concerning your basic language usage example, yes something like that is no problem to implement in Pascal though I favour using routines with their respective names as that allows for a more polished end-user experience. But the different SWI names can be static constants as well, that is no problem.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version