* vector-handlers: <C-function-name>[/<C-function-name>][(<params>)] ...

Several pairs of function names can be given here; each corresponds to an entry point into the module (to be used for OS_Claim or similar) and the name of the C function that that entry point calls. If you omit the '/' and the second half of the pair, then that name is constructed by adding '_handler' on to the end of the first name.
[snip blah]
So, for 'vector-handlers: irq1' the following function is expected:

int wrch_handler(_kernel_swi_regs *r, void *pw);

OK, makes sense now.

Now my module stiffs the machine just by claiming the vector, even though I return 1 to pass it on, as specified here:

Er, you are performing the necessary action(s) to clear all pending interrupts on your device?

Have I missed something?

Edit: Oh, you are passing your module's private word (as passed to your CMHG-generated module init function) as the workspace pointer to xos_claim_device_vector, right?

If you mean in R1, then yes.

I thought you might have made a typo, hence 'R2?'.... R1 = address of interrupt handling routine within device driver, R2 = value passed to interrupt handling routine in R12.... CMHG/CMunge veneers typically (always?) require that the value in R12 is the pointer that was passed to your module_init function and it's used to locate the module's workspace.

I noticed that R3 is being used during the ISR - surely this is a bad thing, but I don't know how to prevent gcc from doing so.

Is anyone using this other than me?