On 6 February 2014 13:59, Joerg Sonnenberger <joerg at britannica.bec.de>wrote:> This is not true. Even for nounwind, you want to get basic tables so > that backtrace(3) works. >Hi Joerg, It's a matter of consensus, I believe. Is it the general consensus that we will *always* want unwind tables to exist? Code size is a clear reason to not want unwind tables at all, but there might not be many more. If the general consensus is that unwind tables are a must, and should only be turned off in special cases, then we just keep emitting them and create (or reuse) a flag to stop it. If not, language / flags decision (-fexception, -g, profiling, etc) should turn them on. However, if every one agrees that, no matter what, we *will* emit unwind tables, than the whole argument is moot, and there is absolutely nothing to "fix" besides removing -arm-disable-ehabi. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/1ec09c29/attachment.html>
Joerg Sonnenberger
2014-Feb-06 14:51 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
On Thu, Feb 06, 2014 at 02:30:11PM +0000, Renato Golin wrote:> On 6 February 2014 13:59, Joerg Sonnenberger <joerg at britannica.bec.de>wrote: > > > This is not true. Even for nounwind, you want to get basic tables so > > that backtrace(3) works. > > > > Hi Joerg, > > It's a matter of consensus, I believe. Is it the general consensus that we > will *always* want unwind tables to exist? Code size is a clear reason to > not want unwind tables at all, but there might not be many more. If the > general consensus is that unwind tables are a must, and should only be > turned off in special cases, then we just keep emitting them and create (or > reuse) a flag to stop it. If not, language / flags decision (-fexception, > -g, profiling, etc) should turn them on. However, if every one agrees that, > no matter what, we *will* emit unwind tables, than the whole argument is > moot, and there is absolutely nothing to "fix" besides removing > -arm-disable-ehabi.My point is that there are two different questions here: (1) Should enough unwind data be provided for a basic, read-only stack walk? (2) Should landing pads etc. be provided for exception handling. The second implies the first, but not the other way around. Some platforms require (1), e.g. AMD64. Debugging in any form is certainly a lot more difficult without. Binary size (not so much code size itself) increases a bit, but typically in the 1-2 per cent range. For NetBSD we are moving to always creating .eh_frame on all platforms as default, because the troubleshooting help justifies the price. That said, the option already exists for changing the default: -funwind-tables. There shouldn't be another ARM specific flag. I can't say what the best default is. Joerg
Hi Joerg, You are right, there are three separate issues here: unwinding, debug info and exception handling. Debug and EH require unwinding, but one doesn't require the other and unwinding is not exclusive to either. On 6 February 2014 14:51, Joerg Sonnenberger <joerg at britannica.bec.de>wrote:> (1) Should enough unwind data be provided for a basic, read-only stack > walk? >As you said, platforms and systems should define their own defaults, and that's mainly driven by the front-end via flags and triples. The behaviour of flags should be precise, and different flags should be on/off by default depending on the triple, so build systems can enforce flags if they need to make sure the behaviour will be the same across different platforms. I can't decide that, but those decisions should stay in the front-end. To the back-end, function attributes should be able to control table emission (or maybe we need flags, I don't know).> That said, the option already exists for changing the default: > -funwind-tables. There shouldn't be another ARM specific flag. >So, can I assume that -f{no-}unwind-tables's syntax is to completely enable/disable the unwind tables and add/remove the ELF sections from the objects? If that's so, I can easily remove -arm-disable-ehabi and check on that flag. thanks, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/26dbccf2/attachment.html>