On 7 February 2014 00:19, Richard Smith <richard at metafoo.co.uk> wrote:> This (-fexceptions and -g imply -funwind-tables) seems like it's probably > the right thing for most targets. With SjLj exceptions, -fexceptions > probably doesn't need -funwind-tables. >Thanks, I think that's the general consensus, yes. Do we have such logic in Clang at the moment? My original point was that the back-end shouldn't try to guess, so front-ends should pass this information down, either via function attributes or flags. Attributes would be better for multi-stage compilation process, but if the default target description is shared between front and back ends, than we might not need this, and flags become the preferred method. This is another reason to proceed with a separate library for target description (that deals with triples, -m flags, defaults, etc), to be used by both front and back ends, so then we don't have to worry about changing all sides whenever a default changes. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140207/f290d450/attachment.html>
On 7 February 2014 09:35, Renato Golin <renato.golin at linaro.org> wrote:> Do we have such logic in Clang at the moment? >Let me answer my own question. Right now, both -funwind-tables and -fno-unwind-tables only enable the -muniwind-tables for -cc1, and either lack or presence of that flag in -cc1 has the same behaviour on C++ code: they both generate .eh_frame sections. The only behaviour I found is that -munwind-tables will add uwtable to functions, which had no effect on x86_64. Is that because x86_64 mandates unwind tables? If the semantics is that uwtable turns on tables on targets that don't require it (SjLj), but not that it turns off if missing on targets that mandate it, I can't use it to disable them on ARM. To be honest, recently, I'm not even sure I need, or want to disable. With Keith's patch to generate Dwarf unwind, the -arm-disable-ehabi flag could possibly be removed clean, and we can go directly to step 2. Keith, Reid, are you happy with always generating unwind tables on ARM regardless? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140207/0c5a65db/attachment.html>
On Feb 7, 2014, at 3:35 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 7 February 2014 09:35, Renato Golin <renato.golin at linaro.org> wrote: > Do we have such logic in Clang at the moment? > > Let me answer my own question. Right now, both -funwind-tables and -fno-unwind-tables only enable the -muniwind-tables for -cc1, and either lack or presence of that flag in -cc1 has the same behaviour on C++ code: they both generate .eh_frame sections. > > The only behaviour I found is that -munwind-tables will add uwtable to functions, which had no effect on x86_64. Is that because x86_64 mandates unwind tables? > > If the semantics is that uwtable turns on tables on targets that don't require it (SjLj), but not that it turns off if missing on targets that mandate it, I can't use it to disable them on ARM. To be honest, recently, I'm not even sure I need, or want to disable. > > With Keith's patch to generate Dwarf unwind, the -arm-disable-ehabi flag could possibly be removed clean, and we can go directly to step 2. > > Keith, Reid, are you happy with always generating unwind tables on ARM regardless?Just to double check, none of this will change the current behavior on Darwin, right? -Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140207/f79494cd/attachment.html>