This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/70216] [SH] Implement __builtin_trap


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> ---
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.

One other thing I'm wondering about is the contract for clobbers on the
function call version. 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, 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? 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]