https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Rich Felker from comment #7) > Is there a reason we don't use an undefined instruction that will trap? > 0xfffd is mentioned as permanently undefined here on page 85: > > http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf > > I actually had trouble getting Linux to trap this; it's one thing I need to > investigate on the kernel side, which is why I didn't reply earlier. I'll > report my findings later. I think it's a bit odd and obscure to use 0xFFFD for this purpose. There are 256 trap numbers to choose from. Unless there's some clear benefit of using 0xFFFD, I'd rather avoid it. > One other thing I'm wondering about is the contract for clobbers on the > function call version. I believe I've mentioned this in the docs section of the patch. The compiler would assume that only the PR is clobbered by the function call. > Is __builtin_trap supposed to be able to return? I > was under the impression that it's noreturn, in which case there would be no > requirements on what it can clobber, That's true. Although it's technically possible for some trap to return, I can't think of any practical case where it would be required. If the function implementation wants to return it has to take care of any other clobbers. My plan was to re-use the same concept for trapping arithmetic (PR 54272), where the trap function could do something like throwing an exception. In any case, I don't think it would want to return to the original code either. On a second thought, it might be better to emit the function call like: sts.l pr,@-r15 jsr @r... nop and officially not clobber PR either. This might be useful when injecting an exception, because the original PR value can be restored. > but there may be calling-convention > issues still: Is it callable via PLT? On FDPIC targets, does the function > receive a valid GOT pointer in r12 so that it can make further calls/data > access? My idea was to have it like any other special support function in libgcc, which are often implemented in asm directly. > Also, if the expectation is that the trap will not return, does the > trapa need the bug workaround? Does the bug (requiring the 5x or) take place > at the time the trapa is executed, or at the time of return to the > instruction after it? This is not well-documented and I remember looking > into it before but I don't remember the answer. I only know tnsh7456ae.pdf which doesn't explain what exactly goes wrong at which stage in the CPU. From what I understand it somehow seems to be related to the instruction prefetching and decoding of the trapa instruction and what follows it.
