On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote:> > if (nounwind) > can't unwind >can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind))> unwind table >"need unwind table to unwind" is probably true in almost all cases. At least in all where ARMException and DwarfCFIException are concerned, which is the ones we're discussing about. I'm beginning to think that there is no reason at all to have an uwtable attribute, given that the -funwind-tables is propagated to the back-end AND if we emit the table for one function we should do it for all. I believe the intent is:> -fexceptions/-fno-exceptions controls whether we generate code that > copes with exceptions passing through it. >Right. Landing pads, cleanups, etc. We'll need those for emitting the EH tables, but not the unwind tables, so for this particular discussion, we don't need to worry.> -fcxx-exceptions/-fno-cxx-exceptions controls whether we allow exception > constructs in C++ code (throw, catch, try) and whether we validate > exception specifications (both during compilation and at runtime). > -fobjc-exceptions/-fno-objc-exceptions controls whether we allow > exception constructs in ObjC code (@throw, @try, @catch). >Language-specific stuff, not even important to the EH tables (since in the back end we don't care what constructs you use in the language, only the IR basic block structure). -fno-exceptions implies -fno-cxx-exceptions and -fno-objc-exceptions> -fcxx-exceptions and -fobjc-exceptions require -fexceptions >Will -fcxx-exceptions also include -fexceptions? I mean, if the user specify -fcxx-exceptions in C, will that also turn on all the internal flags that -fexception would? If so, we really don't need to worry at all about them. -funwind-tables appears to be an entirely orthogonal flag, which is by> default determined based on the target (with some -f flags to override the > default), entirely ignoring the -fexceptions flags and language mode. >Right. They do clash in the back-end, since one generates EH unwinding and the other might only generate Dwarf unwinding. We need to clear that confusion in the back-end, but I don't think that the front-end should even care on how it gets implemented in the end, as long as it works. This does not appear to be a flag that an end-user should touch, under most> circumstances, but it's far from clear to me that we're getting the default > right here (maybe it should depend on -fexceptions?). >I think that both -fexceptions and -g should turn -funwind-tables by default. The third user is the backtrace which doesn't need debug or EH info (just the unwind table), and you need the -funwind-tables IFF your target doesn't have it on by default. I can only think about GPU targets that won't need any of that, but they're not using Dwarf or EHABI handlers, so we shouldn't concern about that. Embedded CPUs might want them disabled to save space, and for that we should actively disable (-fno-unwind-tables or -Os/z). The 'nounwind' attribute is set if -fexceptions is specified, or if we have> some other way of knowing the function does not throw. >You mean -fno-exceptions, I believe. I think this behaviour is correct. The 'uwtable' attribute is set based on the value we determined for> -funwind-tables (either through an explicit flag or from the target). >Seems reasonable, though unnecessary in most cases. This seems wrong -- in C with -fexceptions we do not want nounwind, and> sometimes want uwtable (depending on ABI). >Yes, I agree, I was wrong. Unwind tables are almost entirely orthogonal to EH and Dwarf. Thanks everyone for the enlightening responses, I'll have to digest everything again and see if I remember any of it tomorrow... :) I managed to get a definite step out of this (http://llvm.org/PR18758), and I think we can safely ignore the -fexceptions flags for now. My revised plan: 0. Get Keith's patch in to have unwinding without EH 1. Connect -funwind-tables with EHABI 2. Abstract the unwind code where both EH and the Dwarf producers can make use of 3. Disable unwind tables if -fno-unwind-tables on ARM 4. Apply CFI unwinding if -funwind-tables AND -fno-exceptions on EHABI I'm not sure why we're using .save/.push and not CFI with EHABI, but step 2 would be a lot simpler if we could unify both exception handling classes, and step 4 would completely disappear. Anton/Logan? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/8de3db82/attachment.html>
On Thu, Feb 6, 2014 at 1:27 PM, Renato Golin <renato.golin at linaro.org>wrote:> On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: >> >> if (nounwind) >> can't unwind >> > > can't unwind == unwind table + no EH directives + no EH table > > > if (uwtable || (!nounwind && need uwtable to unwind)) >> unwind table >> > > "need unwind table to unwind" is probably true in almost all cases. At > least in all where ARMException and DwarfCFIException are concerned, which > is the ones we're discussing about. > > I'm beginning to think that there is no reason at all to have an uwtable > attribute, given that the -funwind-tables is propagated to the back-end AND > if we emit the table for one function we should do it for all. > > > I believe the intent is: >> -fexceptions/-fno-exceptions controls whether we generate code that >> copes with exceptions passing through it. >> > > Right. Landing pads, cleanups, etc. We'll need those for emitting the EH > tables, but not the unwind tables, so for this particular discussion, we > don't need to worry. > > > >> -fcxx-exceptions/-fno-cxx-exceptions controls whether we allow >> exception constructs in C++ code (throw, catch, try) and whether we >> validate exception specifications (both during compilation and at runtime). >> -fobjc-exceptions/-fno-objc-exceptions controls whether we allow >> exception constructs in ObjC code (@throw, @try, @catch). >> > > Language-specific stuff, not even important to the EH tables (since in the > back end we don't care what constructs you use in the language, only the IR > basic block structure). > > > -fno-exceptions implies -fno-cxx-exceptions and -fno-objc-exceptions >> -fcxx-exceptions and -fobjc-exceptions require -fexceptions >> > > Will -fcxx-exceptions also include -fexceptions? I mean, if the user > specify -fcxx-exceptions in C, will that also turn on all the internal > flags that -fexception would? > > If so, we really don't need to worry at all about them. >-fcxx-exceptions implies -fexceptions if the input kind is C++ and is ignored if not. -fobjc-exceptions implies -fexceptions if the input kind is ObjC(++) and is ignored if not. Which isn't quite what you asked, but I think the conclusion is the same (you don't need to care, the driver does the right thing).> -funwind-tables appears to be an entirely orthogonal flag, which is by >> default determined based on the target (with some -f flags to override the >> default), entirely ignoring the -fexceptions flags and language mode. >> > > Right. They do clash in the back-end, since one generates EH unwinding and > the other might only generate Dwarf unwinding. We need to clear that > confusion in the back-end, but I don't think that the front-end should even > care on how it gets implemented in the end, as long as it works. >This does not appear to be a flag that an end-user should touch, under most>> circumstances, but it's far from clear to me that we're getting the default >> right here (maybe it should depend on -fexceptions?). >> > > I think that both -fexceptions and -g should turn -funwind-tables by > default. The third user is the backtrace which doesn't need debug or EH > info (just the unwind table), and you need the -funwind-tables IFF your > target doesn't have it on by default. > > I can only think about GPU targets that won't need any of that, but > they're not using Dwarf or EHABI handlers, so we shouldn't concern about > that. Embedded CPUs might want them disabled to save space, and for that we > should actively disable (-fno-unwind-tables or -Os/z). >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. The 'nounwind' attribute is set if -fexceptions is specified, or if we>> have some other way of knowing the function does not throw. >> > > You mean -fno-exceptions, I believe. I think this behaviour is correct. >The 'uwtable' attribute is set based on the value we determined for>> -funwind-tables (either through an explicit flag or from the target). >> > > Seems reasonable, though unnecessary in most cases. > > > This seems wrong -- in C with -fexceptions we do not want nounwind, and >> sometimes want uwtable (depending on ABI). >> > > Yes, I agree, I was wrong. Unwind tables are almost entirely orthogonal to > EH and Dwarf. > > > Thanks everyone for the enlightening responses, I'll have to digest > everything again and see if I remember any of it tomorrow... :) > > I managed to get a definite step out of this (http://llvm.org/PR18758), > and I think we can safely ignore the -fexceptions flags for now. > > My revised plan: > > 0. Get Keith's patch in to have unwinding without EH > 1. Connect -funwind-tables with EHABI > 2. Abstract the unwind code where both EH and the Dwarf producers can make > use of > 3. Disable unwind tables if -fno-unwind-tables on ARM > 4. Apply CFI unwinding if -funwind-tables AND -fno-exceptions on EHABI > > I'm not sure why we're using .save/.push and not CFI with EHABI, but step > 2 would be a lot simpler if we could unify both exception handling classes, > and step 4 would completely disappear. Anton/Logan? > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/defd33c1/attachment.html>
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>