Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs. never-exceptional cases. 1. C vs. C++ We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, nothrow, etc) and uwtable, which forces generation of the table regardless of nounwind. It seems sensible that C++ code with exceptions enabled should generate the tables for all functions, in case they're called by (or call) external functions. In C we don't want any of that. GCC seems to never emit tables, and G++ always do, even on C code (.c files, no exception or anything), which is very sensible and in line with my reasoning above. Clang, on the other hand, always generates them. I guess it'll have to figure out what to do based on its impressions on what language is being used to produce similar results. I believe that emitting the tables on anything that could potentially interact with exceptional code makes sense, but that's clearly a front-end decision. To LLVM, nounwind and uwtables should be absolute: IF (uwtables) IF (nownwind) CantUnwind ELSE Unwind Table ELSE do nothing ENDIF 2. .fnstart/.fnend+friends Another problem is that the emission of unwinding tables (based on .fnstart/.fnend symbols and others) is conditional *only* to the existence (or not) of an exception handling class being loaded (EHABI, Dwarf). Which means that, we can't disable the EH on a per-function basis. We'll have to change the way these symbols are emitted, at least when using ARMException, so that we can emit the tables and honour the uwtable on a per-function basis. Again, this is a requirement for problem 1, but it'd need to be fixed after 3. 3. Unwinding code Currently, even when no exception handling are needed, the exception code is used to generate Dwarf unwinding directives (CFI) for the debugger. Both DwarfCFIException and ARMException inherit from DwarfException, and they are called to do the debug info about the stack unwinding, which is (at least) misplaced. The consensus is that this code should be factored out. The part that is relevant to this thread is that, today, if -arm-disable-ehabi is requested, ARMException will not be used and we won't have a way of generating debug stack directives, which is wrong. Factoring out this code is a requirement for the unwinding problem (1), since if we disable EH today, we'll disable Dwarf stack unwinding altogether. But we also need a final solution for problem 4 below before we start. 4. Clang EH control There are a number of Clang/LLVM options to control exception handling: * -fno-excetpion (enable/disable EH on C++ mode, off in C mode) * -fcxx-exception (no idea, is it objC++ specific? does it control tables in any way?) * -funwind-tables (forces uwtable attribute?) * -arm-disable-ehabi (ARM specific bogus flag) Those options are not always completely exclusive, and they damage different parts of the compilation process (as seen recently on the list), so we need a clear consensus on what each option mean (or should mean), and translate it to the back-end (via function attributes). This would considerably simplify the back-end and help us tackle this refactoring. My main target for this problem is to have the one true option on the front-ends, and rely only on function attributes on the back-end (including tools like llc). For that, I'd love to be left with -fexception only and infer all the rest from the language / conditions of the code. Ex: IF (C++ mode) IF (-fno-exception) no uwtable no nounwind ELSE uwtable IF (leaf / nothrow) nounwind ENDIF ENDIF ELSE no uwtable no nounwind ENDIF My main goal is to get rid of (at least) -arm-disable-ehabi. Finally, If you got this far, you're *really* interested in making the exception handling more user/dev friendly in LLVM, so I welcome any critics about the "proposal" above, as well as any explanations of the doubts expressed. I may be wrong about many things, feel free to enlighten me! We may have a lot less work to do, and I'll be happy. ;) I believe the dependency graph of the solutions are: 4 -> 3 -> 2 -> 1 So, we first should solve the flags problem, than refactor the unwinding code out of EH, make the debug generation use them as well, and then we can start with the EH specific changes. The problem is that 4 will change things considerably, so we might need some scaffolding during the whole process. Makes sense? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/f53b78ed/attachment.html>
Joerg Sonnenberger
2014-Feb-06 13:59 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
On Thu, Feb 06, 2014 at 01:29:43PM +0000, Renato Golin wrote:> We have two unwind flags: nounwind, which flags functions that can't unwind > (leaf, nothrow, etc) and uwtable, which forces generation of the table > regardless of nounwind. It seems sensible that C++ code with exceptions > enabled should generate the tables for all functions, in case they're > called by (or call) external functions. In C we don't want any of that.This is not true. Even for nounwind, you want to get basic tables so that backtrace(3) works. Joerg
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>
> From: Renato Golin [mailto:renato.golin at linaro.org] > > We're having some discussions about the behaviour of exception handling and Dwarf > sharing unwind logic, tables, etc. and it seems that the code around it wasn't > designed with any particular goal in mind, but evolved (like the EHABI) and now > we're seeing the results from it. > > The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional > vs. never-exceptional cases. > > > 1. C vs. C++ > > We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, > nothrow, etc) and uwtable, which forces generation of the table regardless of > nounwind. It seems sensible that C++ code with exceptions enabled should generate > the tables for all functions, in case they're called by (or call) external functions. > In C we don't want any of that. > > GCC seems to never emit tables, and G++ always do, even on C code (.c files, > no exception or anything), which is very sensible and in line with my reasoning above. > Clang, on the other hand, always generates them. I guess it'll have to figure out what > to do based on its impressions on what language is being used to produce similar results.You can make GCC emit unwind tables for C if you use the command line option -funwind-tables. This could be useful if you are compiling C code which is called by C++ code and which itself calls C++ code and you wish the C++ exception to propagate through the C code.> I believe that emitting the tables on anything that could potentially interact > with exceptional code makes sense, but that's clearly a front-end decision. > To LLVM, nounwind and uwtables should be absolute:> IF (uwtables) > IF (nownwind) > CantUnwind > ELSE > Unwind Table > ELSE > do nothing > ENDIFThis certainly appears to me a sensible sequence of decision.> 2. .fnstart/.fnend+friends > > Another problem is that the emission of unwinding tables (based on > .fnstart/.fnend symbols and others) is conditional *only* to the existence > (or not) of an exception handling class being loaded (EHABI, Dwarf). Which > means that, we can't disable the EH on a per-function basis. > > We'll have to change the way these symbols are emitted, at least when using > ARMException, so that we can emit the tables and honour the uwtable on a per-function basis. > > Again, this is a requirement for problem 1, but it'd need to be fixed after 3. > > > 3. Unwinding code > > Currently, even when no exception handling are needed, the exception code is > used to generate Dwarf unwinding directives (CFI) for the debugger.This is because the 2 are so similar.> Both DwarfCFIException and ARMException inherit from DwarfException, and they > are called to do the debug info about the stack unwinding, which is (at least) > misplaced. The consensus is that this code should be factored out.There is some interaction in that if you are generating a .eh_frame section for exception handling then there is little sense is generating a DWARF .debug_frame section as well; I would hope most debuggers could use the .eh_frame section if present as its format is so similar to a .debug_frame section.> The part that is relevant to this thread is that, today, if -arm-disable-ehabi > is requested, ARMException will not be used and we won't have a way of > generating debug stack directives, which is wrong.What does -arm-disable-ehabi actually mean? Currently it is effectively "don't generate exception tables". Maybe is should it rather be "don't generate EHABI exception tables but generate .eh_frame tables instead"? Obviously this requires the necessary DWARF like support to generate the information for the .eh_frame tables.> Factoring out this code is a requirement for the unwinding problem (1), since > if we disable EH today, we'll disable Dwarf stack unwinding altogether. But we > also need a final solution for problem 4 below before we start.I think the solution depends on what we mean when we specify -arm-disable-ehabi ... is it IF(arm_disable_ehabi) USE ARMException ELSE USE DwarfCFiNoException <---- Just generates DWARF debugging information ENDIF Or is it IF(arm_disable_ehabi) USE ARMException ELSE USE DwarfCFIException ENDIF> 4. Clang EH control > > There are a number of Clang/LLVM options to control exception handling: > * -fno-excetpion (enable/disable EH on C++ mode, off in C mode) > * -fcxx-exception (no idea, is it objC++ specific? does it control tables in any way?) > * -funwind-tables (forces uwtable attribute?) > * -arm-disable-ehabi (ARM specific bogus flag) > > Those options are not always completely exclusive, and they damage different > parts of the compilation process (as seen recently on the list), so we need > a clear consensus on what each option mean (or should mean), and translate it > to the back-end (via function attributes). This would considerably simplify > the back-end and help us tackle this refactoring. > > My main target for this problem is to have the one true option on the front-ends, > and rely only on function attributes on the back-end (including tools like llc). > For that, I'd love to be left with -fexception only and infer all the rest from > the language / conditions of the code. > > Ex: > > IF (C++ mode) > IF (-fno-exception) > no uwtable > no nounwind > ELSE > uwtable > IF (leaf / nothrow) > nounwind > ENDIF > ENDIF > ELSE > no uwtable > no nounwind > ENDIF > > My main goal is to get rid of (at least) -arm-disable-ehabi.Hmmm! I'm very nervous about the backend making decisions based on the language. As I mentioned above I also wonder if you do still need to support -funwind-tables for compiling C code through which you wish to allow exceptions to propogate. In which case the logic is more like .... IF (-funwind-tables || -fexceptions) uwtable IF (leaf / nothrow) nounwind ENDIF ELSE no uwtable no nounwind ENDIF The main difference I see between -fexceptions and -funwind-tables is: -fexceptions allows compiling exception handling constructs in the source language and enables the generation of unwind tables. -funwind-tables only enables the generation of unwind tables. Keith Keith -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 6 February 2014 18:02, Keith Walker <Keith.Walker at arm.com> wrote:> You can make GCC emit unwind tables for C if you use the command line > option -funwind-tables. > > This could be useful if you are compiling C code which is called by C++ > code and which itself calls C++ code and you wish the C++ exception to > propagate through the C code. >Yes, we still need the possibility to force unwind tables in C code, and that's what -funwind-tables is there for. Since -fexception only triggers landing pads and cleanup blocks, we don't need to worry about it, but the -funwind-tables should communicate with the back-end via some clear and unambiguous means. Maybe function attributes aren't enough, but we need to make sure that they don't clash with the flags, if we do use them. There is some interaction in that if you are generating a .eh_frame section> for exception handling then there is little sense is generating a DWARF > .debug_frame section as well; I would hope most debuggers could use the > .eh_frame section if present as its format is so similar to a .debug_frame > section. >Right, makes sense. It seems, then, that we basically need two types of unwinding, and they could live in different places. Before your patch, the debugger wasn't able to use the EHABI stack unwinding code. Is that because it was using .push/.save instead of .cfi directives? Or is that because the table generated is not readable by normal debuggers? What does -arm-disable-ehabi actually mean?> > Currently it is effectively "don't generate exception tables". >Yes. It has no effect on the front-end. It should actually be replaced by whatever mechanism -f{no-}unwind-tables is using. I created a bug (PR18758) and copied you. Maybe is should it rather be "don't generate EHABI exception tables but> generate .eh_frame tables instead"? Obviously this requires the necessary > DWARF like support to generate the information for the .eh_frame tables. >This is where things start getting a little interesting. If we all agree that generating unwind tables is good *in any case*, even on embedded devices like Coretx-M0, than I think we should hard-code .eh_frame generation under any circumstance, and use -funwind-tables to generate EHABI tables. Clang would then enable it by default depending on the language contract, which is of little importance to the back-end. But the question I don't have an answer yet is: if we use that flag, what do we do when -fno-unwind-tables clashes with the uwtables function attribute? IF(arm_disable_ehabi)> USE ARMException > ELSE > USE DwarfCFIException > ENDIF >Today, it means: IF(arm_disable_ehabi) nothing at all ELSE USE ARMException ENDIF I'm sensing that the consensus is driving towards *always* emitting unwind tables, but I can't just use DwarfCFIException on ARM, it won't work. This is why we need to carefully extract the common interface, not just for the debug x EH problem, but also the Dwarf x EHABI problem. Hmmm! I'm very nervous about the backend making decisions based on the> language. >No, sorry! That was a front-end decision! I'd die before enquiring the language in the back-end! :D IF (-funwind-tables || -fexceptions)> uwtable > IF (leaf / nothrow) > nounwind > ENDIF > ELSE > no uwtable > no nounwind > ENDIF >I'd only like to completely remove the unwind tables if the user forcefully selected -fno-unwind-tables, so I wouldn't like Clang to automatically select that, even in C code. -fexceptions allows compiling exception handling constructs in the source> language and enables the generation of unwind tables. > -funwind-tables only enables the generation of unwind tables. >That makes total sense. Right now, I can't see a difference between -fno-unwind-tables and -arm-disable-ehabi. As far as I could see, -fcxx-exceptions has no relevance to this discussion, so I'll drop it right here. My questions about the flags were answered, and it's going to be a lot easier than I thought. I'll change the ehabi flag to connect via unwind-tables and will send a patch review. Once that's done, we can get some work done on refactoring ARMException, but only after your patch lands upstream. Thanks! --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/b28466d9/attachment.html>
On Thu, Feb 6, 2014 at 5:29 AM, Renato Golin <renato.golin at linaro.org>wrote:> Folks, > > We're having some discussions about the behaviour of exception handling > and Dwarf sharing unwind logic, tables, etc. and it seems that the code > around it wasn't designed with any particular goal in mind, but evolved > (like the EHABI) and now we're seeing the results from it. > > The problems below are assuming C vs. C++, but it actually apply to any > possibly-exceptional vs. never-exceptional cases. > > > 1. C vs. C++ > > We have two unwind flags: nounwind, which flags functions that can't > unwind (leaf, nothrow, etc) and uwtable, which forces generation of the > table regardless of nounwind. It seems sensible that C++ code with > exceptions enabled should generate the tables for all functions, in case > they're called by (or call) external functions. In C we don't want any of > that. > > GCC seems to never emit tables, and G++ always do, even on C code (.c > files, no exception or anything), which is very sensible and in line with > my reasoning above. Clang, on the other hand, always generates them. I > guess it'll have to figure out what to do based on its impressions on what > language is being used to produce similar results. > > I believe that emitting the tables on anything that could potentially > interact with exceptional code makes sense, but that's clearly a front-end > decision. To LLVM, nounwind and uwtables should be absolute: > > IF (uwtables) > IF (nownwind) > CantUnwind > ELSE > Unwind Table > ELSE > do nothing > ENDIF >This looks wrong, based on the LangRef: "uwtable This attribute indicates that the ABI being targeted requires that an unwind table entry be produce for this function even if we can show that no exceptions passes by it." I think it's probably: if (nounwind) can't unwind if (uwtable || (!nounwind && need uwtable to unwind)) unwind table 2. .fnstart/.fnend+friends> > Another problem is that the emission of unwinding tables (based on > .fnstart/.fnend symbols and others) is conditional *only* to the existence > (or not) of an exception handling class being loaded (EHABI, Dwarf). Which > means that, we can't disable the EH on a per-function basis. > > We'll have to change the way these symbols are emitted, at least when > using ARMException, so that we can emit the tables and honour the uwtable > on a per-function basis. > > Again, this is a requirement for problem 1, but it'd need to be fixed > after 3. > > > 3. Unwinding code > > Currently, even when no exception handling are needed, the exception code > is used to generate Dwarf unwinding directives (CFI) for the debugger. > > Both DwarfCFIException and ARMException inherit from DwarfException, and > they are called to do the debug info about the stack unwinding, which is > (at least) misplaced. The consensus is that this code should be factored > out. > > The part that is relevant to this thread is that, today, if > -arm-disable-ehabi is requested, ARMException will not be used and we won't > have a way of generating debug stack directives, which is wrong. > > Factoring out this code is a requirement for the unwinding problem (1), > since if we disable EH today, we'll disable Dwarf stack unwinding > altogether. But we also need a final solution for problem 4 below before we > start. > > > 4. Clang EH control > > There are a number of Clang/LLVM options to control exception handling: > * -fno-excetpion (enable/disable EH on C++ mode, off in C mode) > * -fcxx-exception (no idea, is it objC++ specific? does it control tables > in any way?) > * -funwind-tables (forces uwtable attribute?) > * -arm-disable-ehabi (ARM specific bogus flag) > > Those options are not always completely exclusive, and they damage > different parts of the compilation process (as seen recently on the list), > so we need a clear consensus on what each option mean (or should mean), and > translate it to the back-end (via function attributes). This would > considerably simplify the back-end and help us tackle this refactoring. >I believe the intent is: -fexceptions/-fno-exceptions controls whether we generate code that copes with exceptions passing through it. -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). So: -fno-exceptions implies -fno-cxx-exceptions and -fno-objc-exceptions -fcxx-exceptions and -fobjc-exceptions require -fexceptions The (-cc1) frontend defaults to -fno-exceptions -fno-cxx-exceptions -fno-objc-exceptions (I'm not sure why). The driver defaults to: * in ObjC++: -fcxx-exceptions -fobjc-exceptions -fexceptions * in ObjC: -fobjc-exceptions -fexceptions * in C++: -fcxx-exceptions -fexceptions * in C: <nothing> (Users might want to specify -fexceptions in C, when building code like qsort that might have exceptions thrown across it.) -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. 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?). The 'nounwind' attribute is set if -fexceptions is specified, or if we have some other way of knowing the function does not throw. Exception: in -fobjc-exceptions mode, we ask the ObjC runtime whether to set the flag. This looks like a bug to me. The 'uwtable' attribute is set based on the value we determined for -funwind-tables (either through an explicit flag or from the target). My main target for this problem is to have the one true option on the> front-ends, and rely only on function attributes on the back-end (including > tools like llc). For that, I'd love to be left with -fexception only and > infer all the rest from the language / conditions of the code. > > Ex: > > IF (C++ mode) > IF (-fno-exception) > no uwtable > no nounwind > ELSE > uwtable > IF (leaf / nothrow) > nounwind > ENDIF > ENDIF > ELSE > no uwtable > no nounwind >This seems wrong -- in C with -fexceptions we do not want nounwind, and sometimes want uwtable (depending on ABI).> ENDIF > > My main goal is to get rid of (at least) -arm-disable-ehabi. > > > > Finally, > > If you got this far, you're *really* interested in making the exception > handling more user/dev friendly in LLVM, so I welcome any critics about the > "proposal" above, as well as any explanations of the doubts expressed. I > may be wrong about many things, feel free to enlighten me! We may have a > lot less work to do, and I'll be happy. ;) > > I believe the dependency graph of the solutions are: > > 4 -> 3 -> 2 -> 1 > > So, we first should solve the flags problem, than refactor the unwinding > code out of EH, make the debug generation use them as well, and then we can > start with the EH specific changes. The problem is that 4 will change > things considerably, so we might need some scaffolding during the whole > process. > > Makes sense? > > cheers, > --renato > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/12b89335/attachment.html>
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>
Rafael EspĂndola
2014-Feb-10 02:54 UTC
[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM
On 6 February 2014 08:29, Renato Golin <renato.golin at linaro.org> wrote:> Folks, > > We're having some discussions about the behaviour of exception handling and > Dwarf sharing unwind logic, tables, etc. and it seems that the code around > it wasn't designed with any particular goal in mind, but evolved (like the > EHABI) and now we're seeing the results from it. > > The problems below are assuming C vs. C++, but it actually apply to any > possibly-exceptional vs. never-exceptional cases. > > > 1. C vs. C++ > > We have two unwind flags: nounwind, which flags functions that can't unwind > (leaf, nothrow, etc) and uwtable, which forces generation of the table > regardless of nounwind. It seems sensible that C++ code with exceptions > enabled should generate the tables for all functions, in case they're called > by (or call) external functions. In C we don't want any of that.Depends on the ABI. On X86-64 we should produce the tables even with C according to the ABI. Cheers, Rafael