@mfukar @whitequark @jfbastien @johnregehr Yes, arm is missing a proper a_crash. What's the right guaranteed-undefined instruction to use?
-
-
Replying to @RichFelker
@RichFelker@mfukar@whitequark@johnregehr you want UDF #65006 in ARM and Thumb, most OSes translate that to SIGTRAP.1 reply 0 retweets 0 likes -
-
Replying to @whitequark
@whitequark@jfbastien musl doesn't use __builtin_trap because some compilers lack it, and some compilers/archs make it a call to abort().3 replies 0 retweets 0 likes -
Replying to @RichFelker
@whitequark@jfbastien Anything but an inline fault-generating instruction is unsafe because GOT, vdso syscall ptr, etc. may be corrupted.1 reply 0 retweets 1 like -
Replying to @RichFelker
@whitequark@jfbastien Alternatively we could do 3 inline syscalls to: 1. block all signals, 2. getpid, 3. kill -9 self.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@jfbastien -KILL? maybe -TRAP. but yeah1 reply 0 retweets 0 likes -
Replying to @whitequark
@whitequark@jfbastien Being non-catchable is desirable here. If state is corrupted, any further execution is dangerous.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@whitequark@jfbastien This is a major bug in gcc/glibc __stack_chk_fail, etc. - the handler can actually turn over code execution!1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@whitequark I asked a glibc maintainer about this, it sounds like that's a design philosophy difference :-)1 reply 0 retweets 0 likes
@jfbastien @whitequark Keep in mind, on x86, the vdso syscall pointer is in the TCB, which is just above the stack on non-main threads...
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.