Toolbox/Wimp error on the OMAP

I have been writing a program that uses the Toolbox, and have been developing it on the Iyonix. When testing on the OMAP port, a simple window open from the icon bar icon locks the machine up. If address exeptions are off, the open works fine.

The problem seems to be connected to checkhandle in Wimp04 of the WindowManager source.

The offending code uses R10 as a pointer with a fixed offset (LDR R0,[R10,#w_guardword]).

when entering this instruction, R10 is equal to 3.

The bit in checkhandle, at line 5840? That should be easy enough to fix:

TST handle,#3
BNE errhandle

Of course, the real question is why are you (or the toolbox!) passing a window handle of 3 to the wimp…

a window handle of 3

Although looking at what the ‘Abs’ macro does, it looks like it must be a window handle of 4 (which the Abs macro translates to a window pointer of 3, via the incredibly high-tech hashing/obfuscation method of substracting 1)

Yes, thats the bit. In the compiled code, the Abs handle,handle at line 5830 compiles to SUB R10,R10,#-1 ?

As to why the handle is only 3 thats a mistery to me as when execptions are off, both wimp and toolbox handles are normal looking.

Also, this is 100% repeatable with the program in question, but not with a different program … The open window request is generated by the icon bar gadget in both cases.

Oops, posts crossed in writing !!!

OK, I seem to have cured it by changing the Show default to Show centred option in the Iconbar setup. Changing it back after saving, all seems well.

Some stray bit in the flag word must have been at fault, but I am suprised this didn’t cause a reserved flags error to show.

On another note, the ROL toolbox modules (the ones I have are dated in 2008) work with the OMAP port….

Another thought , is it worth changing the Abs macro to-

MACRO

Abs $to,$from,$cc

MOV$cc $to,$from,LSR #2

MOV$cc $to,$to,LSL #2

MEND

I have tried this on my BBxM and no problems seem evident.

Wouldn’t the single instruction:

BIC$cc $to,$from,#3

do the same thing as your two MOV instructions?

Ah.. yes.

Does anyone actually know the effect this macro is tying to achieve, is it just to align the address used, or is there a darker objective..

Also, the Rel macro below it in the source just adds 1 as its result, and then is used as a window pointer from where it is called.

Does anyone actually know the effect this macro is tying to achieve, is it just to align the address used, or is there a darker objective..

To me it looks like it’s a primitive method of obfuscating the pointer so that it looks more like an arbitrary ID rather than a pointer which nosey programmers will poke around in.

Plus the act of obfuscating it may help to reveal errors (e.g. if you pass a null pointer to the wimp, the Abs macro would turn it into -1, which would then – at least on machines with a 26 bit address bus – result in a nice data abort). But since the wimp also seems to range check the pointers, and checks for a guard word at a certain position inside each window structure, it’s questionable whether the Abs/Rel macros were designed to help with error checking or not.

It’s probably best to just leave the Abs/Rel code as it is, since it’s not doing any harm and could be rather tricky to remove without introducing lots of hidden bugs.

I’ve now checked in a change so that checkhandle checks that pointers are word aligned.

My suspicion was always that the requirement that the public Wimp API expects window handles to have bit 0 set comes from the menu item structure. Once upon a time (RISC OS 2 I think) there could only be 256 windows open at a time, and window handles happened to use an index number, so submenus could be either dialogue boxes (identified by window handles less than 256) or other menu structures (identified by addresses in the application slot or higher). When this limit was lifted, window handles would still needed to be easily convertible to RMA addresses, yet using an RMA address directly would have made this ambiguous. Older Wimps already assumed menu structure pointers were at least word aligned, so using bit 0 in this way is an obvious choice for expanding the handle pool without breaking compatibility.

Of course, it’s also true that it’s a valuable way to dissuade people from fiddling in internal Wimp data structures – you should always treat all handles as opaque data.

Using ADD/SUB in Abs/Rel rather than BIC/ORR may have been a deliberate attempt to be sensitive to uninitialised or corrupted handles.