http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272
--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-16 12:43:09 UTC --- (In reply to comment #2) > (In reply to comment #1) > > For linux environment, libc's abort function is a rather complex > function and trapa handler should do equivalent things to keep > complete binary compatibility. I guess that it isn't worth to do > so. You can introduce simple trapa sequence as an ABI changing -m > option on linux, though trap numbers < 32 are allocated for the > syscalls and all other numbers are given for debug purposes and > generate SIGTRAP with modified pc which points to trapa instruction > itself. If the user program uses its own SIGTRAP handlers, this > might be problematic. Perhaps the "sleep" instruction will be > a candidate because current libc uses it for ABORT_INSTRUCTION, > though it would be bad for bare metal cases. > BTW, there is a known SH4 core bug for trapa instruction and we > are using 5 or r0,r0 instructions just after trapa. See libitm/ > config/sh/futex_bits.h for example. Thanks a lot for the hints! Just for the record, the SH7750 / SH7751 trapa bug is described here http://documentation.renesas.com/doc/products/mpumcu/tu/tnsh7456ae.pdf Taking this into account, the trapa insn suddenly seems very unattractive for this purpose ;) How about small variation: mov.l .Loverflow_trap, r1 addv r4,r5 bf 0f jsr @r1 0: nop .... 'overflow_trap' then would be a library function in libgcc lib1funcs.S, like e.g. the dynamic shift functions for SH2. The default implementation of overflow_trap could simply invoke abort to stay in line with the other trapping operations in libgcc. For bare metal cases, users can provide their own libgcc implementation and do whatever they want.
