On Thu, Oct 24, 2024 at 05:53:45PM +0100, Richard Sandiford wrote: > Yury Khrustalev <yury.khrusta...@arm.com> writes: > > From: Szabolcs Nagy <szabolcs.n...@arm.com> > > > Don't we still need to pop from the current stack up to the switch point, > in case something further up the call frame wants to switch back to it? > > If so, don't we also need to handle multiple switches, and similarly > pop from intermediate stacks? > > E.g. if we have stacks S1-S3 and functions f1-f4, and a call stack: > > f1 initially uses S1, switches to S2, calls f2 > f2 initially uses S2, switches to S3, calls f3 > f3 initially uses S3, switches to S1, calls f4 > f4 initially uses S1, triggers a longjmp to f2 > > then wouldn't the longjmp need unwind S1 to the switch point; > unwind S3 through f3's entry to the switch point; and then unwind > S2 in the way that the routine currently does? Or is that kind of > situation not supported? This is a valid question and it might require some time to find a good answer and change implementation accordingly. In the v2 of this patch series [1] I have removed the addition of the GCS support in libitm.
When configured and built with branch protection that implies GCS (e.g "standard") libitm will be linked without GCS marker. Thanks, Yury [1] https://inbox.sourceware.org/gcc-patches/20241031132323.948159-1-yury.khrusta...@arm.com/
