On 3/23/21 1:27 PM, Mark Brown wrote: > On Tue, Mar 23, 2021 at 12:23:34PM -0500, Madhavan T. Venkataraman wrote: >> On 3/23/21 12:02 PM, Mark Rutland wrote: > >>> 3. Figure out exception boundary handling. I'm currently working to >>> simplify the entry assembly down to a uniform set of stubs, and I'd >>> prefer to get that sorted before we teach the unwinder about >>> exception boundaries, as it'll be significantly simpler to reason >>> about and won't end up clashing with the rework. > >> So, here is where I still have a question. Is it necessary for the unwinder >> to know the exception boundaries? Is it not enough if it knows if there are >> exceptions present? For instance, using something like num_special_frames >> I suggested above? > > For reliable stack trace we can live with just flagging things as > unreliable when we know there's an exception boundary somewhere but (as > Mark mentioned elsewhere) being able to actually go through a subset of > exception boundaries safely is likely to help usefully improve the > performance of live patching, and for defensiveness we want to try to > detect during an actual unwind anyway so it ends up being a performance > improvment and double check rather than saving us code. Better > understanding of what's going on in the presence of exceptions may also > help other users of the unwinder which can use stacks which aren't > reliable get better results. > Actually, I was not suggesting that the counter replace the unwinder intelligence to recognize exception boundaries. I was only suggesting the use of the counter for arch_stack_walk_reliable(). But I am fine with not implementing the counter for now. Madhavan
