On 2020-02-29 05:49, Florian Weimer wrote: > * J. W. Jagersma: > >> On 2020-02-28 22:32, Florian Weimer wrote: >>> * J. W. Jagersma: >>> >>>> The call instruction is just a practical example. The problem I want to >>>> address is that no exception handling information is generated at all >>>> for asm statements. Other operations, eg. memory access, division, etc >>>> could trap and throw an exception. The unwind tables should cover this. >>> >>> I think permitted uses of asm cannot do anything that would make the >>> tables invalid, at least for DWARF unwinding information. >> >> I don't see how a trapping instruction in asm would invalidate the >> unwind table. An explicit call, maybe, but as I said that was only an >> example. The problem is that there is no unwind table at all. >> >>> DWARF does not need to annotate any instruction that might throw (which >>> would be every instruction in case of asynchronous unwind tables). >> >> But it should, if the instruction appears in a try block. Without that >> it is impossible to catch the exception. > > I don't think this is true. DWARF unwind information is range-based, > after all. The asm statement will be covered by the unwinding > information for the surrounding code. But when there is only an asm statement in the try block, no unwind information is generated at all. There is no EH range that covers the asm. That is exactly the problem. Even when surrounded by other code that may throw, the entry in the unwind table that covers the asm explicitly has no landing pad (catch block) associated with it, so the only out way from there is a direct call to std::terminate. I did some digging and found a way to solve this issue. I have submitted a bug report with this proposed patch here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 Ideally though, with -fasynchronous-unwind-tables I think gcc could emit just one EH region that spans the entire try block, instead of considering for each individual instruction if it could throw or not. That would make the unwind tables truly asynchronous.
