search for: ehtable

...ur to be expressed by a flag, and during the discussion, merge similar behaviour and possibly remove unused flags along the way. Today we have uwtable and nothrow, which are interchangeably being used to mean debug and EH unwinding, which is just wrong. Logan's proposal is to split uwtable and ehtable, nothrow and nounwind and to understand which trumps which if combined. In my view, nounwind has no purpose. I may be wrong, but I can't think of a case where you want to generate debug unwind tables and NOT want to unwind a particular function on a purely non-EH context. Supposing nounwind ha...

...t. * The no-unwind attribute guarantees that the function won't read the prior calling sequence with the stack unwinder. For simplification, if the function is not tagged with no-throw then it is may-throw. Similarly, if the function is not tagged with no-unwind, then it is may-unwind. * The ehtable attribute guarantees that the exception handling table, such as the LSDA handler data and (by implementation) the stack unwinding information for exception, will be generated for exception handling. If the table includes stack unwinding infomration, then it is guaranteed that the unwinding informat...

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

...able and nounwind. Those were made with the x86_64's ABI in mind, and have only interoperated seriously with DwarfCFIException until very recently. There has to be a way to disable unwind tables, so either the "no attribute" behaviour above is wrong or we need a new attribute "noehtable". There has to be a way to emit CantUnwind, so if the behaviour above is right, the "uwtables" attribute is only related to forced unwind (debug, profiler), not exception handling. There has to be a way to map "throw()" into IR, and "nounwind" seems to be the on...