search for: d3079

...ly 8-12 bytes per function. If this is > still an issue, then -fno-unwind-table might be a solution (i.e. at llvm > assembly level, the function should be marked with nounwind and without > uwtable.) Yes, and that's what my merge request implements: http://llvm-reviews.chandlerc.com/D3079 As soon as that's in, I believe EHABI is finally in good shape to be called Beta. Since the 3.4 release I'm trying to get the EHABI and IAS support in good shape (removing the final restraints, testing a lot), for them to be enabled by default in 3.5, and I think we got it, thanks to you,...

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from exceptional logic which I think we should give it a try. I'm trying to make it as backward compatible as possible, but the point is to make the IR authorita...

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly