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>
Joerg Sonnenberger
2014-Feb-06 15:47 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
On Thu, Feb 06, 2014 at 03:18:02PM +0000, Renato Golin wrote:> Debug and EH require unwinding, but one doesn't require the other and > unwinding is not exclusive to either.Correct.> 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).I disagree on this. Table emission by itself doesn't involve code generation and I don't think it makes sense as a per function attribute either. You either want it for all functions or only when needed (e.g. exceptions are possible). As such, it makes perfect sense to me as a global flag.> > 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.-funwind-tables says that the tables should always be emitted. If there are no other reasons like exception handling, they will only destructive stack unwind. -fno-unwind-tables says that tables should only be emitted, if another (language specific) reason requires them. So for C++, it would normally be ignored as exception support is the default. For C code, it would ensure that no .eh_frame* sections are emitted, even on platforms that require them for the ABI like AMD64. Joerg
Stephen Checkoway
2014-Feb-06 20:01 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
On Feb 6, 2014, at 10:47 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> On Thu, Feb 06, 2014 at 03:18:02PM +0000, Renato Golin wrote: >> 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). > > I disagree on this. Table emission by itself doesn't involve code > generation and I don't think it makes sense as a per function attribute > either. You either want it for all functions or only when needed (e.g. > exceptions are possible). As such, it makes perfect sense to me as a > global flag.Does LTO change this analysis? -- Stephen Checkoway
Rafael EspĂndola
2014-Feb-10 02:59 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
> I disagree on this. Table emission by itself doesn't involve code > generation and I don't think it makes sense as a per function attribute > either. You either want it for all functions or only when needed (e.g. > exceptions are possible). As such, it makes perfect sense to me as a > global flag.It has to be an attribute because of LTO. You can LTO a file compiled with -fasynchronous-unwind-tables and one with -fno-asynchronous-unwind-tables. That is why we have the uwtable attribute. Cheers, Rafael