Usefulness of xbra.h

[mikrosk]

While looking into https://github.com/freemint/mintlib/blob/master/include/mint/xbra.h I have found a couple of issues with it:

• it uses a self-modifying code (perhaps that was what OP meant here) for jumping to the original vector
• I'm really not sure what is the code #define _TRAP_VEC(n,x) ((void (*) __P((void))) (((long) n << 24) | (long) &(x.jump))) for -- it looks like it assumes that &(x.jump) is located in ST-RAM (?) and creates some magic function pointer with masking n into bits 31-24.
• what is the use case for _TRAP_INIT ?
• if xbra_struct::this is a C function, it unnecessarily stores d2/a2 (those are going to be stored by any TOS call in osbind.h anyway)
• most importantly (and this is what most apps ignore completely due to the task's complexity), it lacks something like unhook_xbra, I'm not even sure if it's possible to create a legal unhook function with usage of xbra_struct (where the actual custom vector isn't anywhere near the 'XBRA' header) ?

I'm tempted to propose removal of this file completely, unless somebody wants to rework it (at least that SMC code could have been reworked as inline assembly loading this into an address register & jump).

[mikrosk]

I'm not even sure if it's possible to create a legal unhook function with usage of xbra_struct (where the actual custom vector isn't anywhere near the 'XBRA' header) ?

There is even a bigger problem - all XBRA IDs are set to 'GNUC', therefore making the whole thing really useless. (this has been solved by a fixed unhook_xbra but the issue quoted persists -- I have no clue how to fix it).

[th-otto]

I don't know where you see any self-modifying code, or where it stores d2/a2, but the TRAP_VEC macro really looks very suspicious. Do you know of any code that makes use of that header?

[mikrosk]

I don't know where you see any self-modifying code

There is a JMP/JSR instruction followed by an absolute address. If this structure happens to be a part of text segment (i.e. static) and near some function which has been executed, instruction burst cache can preload this part of file, ignoring any further data writes.

where it stores d2/a2

That is why I write "if xbra_struct::this is a C function", every C function, should it use d2/a2, stores them because gcc uses only d0-d1/a0-a1 as scratch registers.

Do you know of any code that makes use of that header?

I don't. That is why I'm inclined to remove it before it makes further damage. :)