[PATCH] Fix PR84521
Tue Jun 18 00:58:00 GMT 2019
> So I like the significant simplification here. My worry is whether or
> not this is, in effect, an ABI change. ie, would we be able to mix and
> match .o files from before/after this change which used the builtin
> setjmp/longjmp bits?
No it's not an ABI change. It does affect the value stored in the setjmp
record, but that is entirely local to the function containing setjmp.
Note that the function containing the longjmp is not affected by this
> You mention that arm, mips and xtensa are still broken. Are they worse
> after this patch? Presumably for arm/mips the problem is the frame
> pointer varies based on the thumb/mips and mips/mips16 state? Is it
> even valid to longjmp from one mode to the other?
Yes the only remaining issue after this is the fact that these targets can use
different frame pointers in functions. The generic code doesn't consider this,
but any function could be Arm or Thumb, mips or mips16. One solution
would be to pass the frame pointer in an argument register (that would be
an ABI change).
> I think xtensa has two abis and the frame pointer is different across
> them. Presumably a longjmp from one abi to the other isn't valid.
If it isn't possible to call functions with the other frame pointer then it
won't be affected.
More information about the Gcc-patches