On 6/17/19 6:58 PM, Wilco Dijkstra wrote: > Hi Jeff, > >> 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 > change. OK. Thanks for the clarification.
> >> 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). ACK. I think if we want to make this work (arm <-> thumb or mips <-> mips16) then we should take that up separately. > >> 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. I'd be surprised given it's two distinct abis as opposed to a processor mode change like we see in the arm/mips cases. OK for the trunk. Thanks for your patience. jeff
