[cfe-dev] [LLVMdev] Unwind behaviour in Clang/LLVM

[Joerg Sonnenberger]

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