On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote: > You have to save the stack pointer at the setjmp point too. And there > might be other architecture-specific ABI rules for that. But you're > right, it might be worth it. > > I *would* be a bit worried about code generation issues. > setjmp/longjmp is so seldom used that it's one of those things where > it might be best to verify with some gcc person that it doesn't cause > huge code-gen problems. > > Adding Jakub just to check: Jakub, would a setjump/longjump kind of > interface for exception handling going to cause us problems > (performance or correctness) with gcc? If you plan to use setjmp/longjmp a lot, then it is certainly a major performance and compile time/memory problem. Older versions don't model it properly, and newer gccs emit abnormal edges from every longjmp or call that might longjmp to an artificial basic block and from there to every setjmp. Also note that gcc has/supports two setjmp kind of APIs, normal setjmp and slightly more lightweight __builtin_setjmp which saves fewer registers, and on some targets is/used to be used for EH instead of DWARF based ones. Jakub -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
