Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly when not using the integrated assembler), and it seems there GCC also emits both EHABI directives and Dwarf, so I don't think we'll be able to move away from it. Since this is only relevant in debug/profiling mode, and the only problem is code size, I think this is something we can live with. Do you guys agree with it? Another issue is the usage of EH tables in C code. I believe the consensus is that it may not be the most optimal for never-exceptional code, but it's the safest default option. The only thing remaining is to choose a way to disable them via some flag. As weird as -fno-exceptions sounds for C code, I think we'll have to go with it. Any other ideas? Finally, Keith, do you have some internal EHABI test you can run Clang on? Does any one know of a large, self contained code, that makes heavy use of exceptions? cheers, --renato
Renato> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > > Last time we spoke about ARM unwinding, we agreed to have both CFI and > directive variants in ARM, so that both EH and debuggers/profilers > could correctly unwind the stack. The problem, obviously, is that we > now have redundant information and I decided to have a go commoning > them up. > > One of the issues, I think, is GNU compatibility (so GAS can generate > the tables correctly when not using the integrated assembler), and it > seems there GCC also emits both EHABI directives and Dwarf, so I don't > think we'll be able to move away from it. Since this is only relevant > in debug/profiling mode, and the only problem is code size, I think > this is something we can live with. Do you guys agree with it?I think for the moment this is a sensible stance as it ensure maximum compatibility with debuggers who might understand DWARF but not EHABI generated tables.> Another issue is the usage of EH tables in C code. I believe the > consensus is that it may not be the most optimal for never-exceptional > code, but it's the safest default option. The only thing remaining is > to choose a way to disable them via some flag. As weird as > -fno-exceptions sounds for C code, I think we'll have to go with it. > Any other ideas?It does seem strange if you are only compiling C code you have to specify -fno-exceptions in order to not generated the overhead of the exception tables. Personally, it would appear to be more correct to require the use of -fexceptions if you want the overhead of exception tables when compiling C. However I can see that this may result in people not using -fexecptions when they should and programs failing at runtime because of it. Whilst not specifying -fno-exceptions just results in a slightly larger image.> Finally, Keith, do you have some internal EHABI test you can run Clang > on? Does any one know of a large, self contained code, that makes > heavy use of exceptions?The EHABI specific tests that we have, test the ARM EHABI personality routines whilst clang generates exception handling that use the GCC personality routines. Otherwise the tests we have are generic exception handling tests that are part of C++ language tests suites. 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
Renato> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > > Last time we spoke about ARM unwinding, we agreed to have both CFI and > directive variants in ARM, so that both EH and debuggers/profilers > could correctly unwind the stack. The problem, obviously, is that we > now have redundant information and I decided to have a go commoning > them up. > > One of the issues, I think, is GNU compatibility (so GAS can generate > the tables correctly when not using the integrated assembler), and it > seems there GCC also emits both EHABI directives and Dwarf, so I don't > think we'll be able to move away from it. Since this is only relevant > in debug/profiling mode, and the only problem is code size, I think > this is something we can live with. Do you guys agree with it?I think for the moment this is a sensible stance as it ensure maximum compatibility with debuggers who might understand DWARF but not EHABI generated tables.> Another issue is the usage of EH tables in C code. I believe the > consensus is that it may not be the most optimal for never-exceptional > code, but it's the safest default option. The only thing remaining is > to choose a way to disable them via some flag. As weird as > -fno-exceptions sounds for C code, I think we'll have to go with it. > Any other ideas?It does seem strange if you are only compiling C code you have to specify -fno-exceptions in order to not generated the overhead of the exception tables. Personally, it would appear to be more correct to require the use of -fexceptions if you want the overhead of exception tables when compiling C. However I can see that this may result in people not using -fexecptions when they should and programs failing at runtime because of it. Whilst not specifying -fno-exceptions just results in a slightly larger image.> Finally, Keith, do you have some internal EHABI test you can run Clang > on? Does any one know of a large, self contained code, that makes > heavy use of exceptions?The EHABI specific tests that we have, test the ARM EHABI personality routines whilst clang generates exception handling that use the GCC personality routines. Otherwise the tests we have are generic exception handling tests that are part of C++ language tests suites. Keith
On 13 March 2014 16:48, Keith Walker <Keith.Walker at arm.com> wrote:> Whilst not specifying -fno-exceptions just results in a slightly larger image.Yes, it becomes a nuisance, not a failure. If you use g++ on C code, you get the EH tables, but not if you use gcc. Having two separate entry points help, but I don't think that clang/clang++ is in such a position to so the same (I never use clang++, maybe I should...). cheers, --renato
> One of the issues, I think, is GNU compatibility (so GAS can generate > the tables correctly when not using the integrated assembler), and it > seems there GCC also emits both EHABI directives and Dwarf, so I don't > think we'll be able to move away from it. Since this is only relevant > in debug/profiling mode, and the only problem is code size, I think > this is something we can live with. Do you guys agree with it?I think emitting both is a good thing, personally. It means that generic tools (and possibly even debuggers, given certain runtime support) can rely on the DWARF standard, not just the bits we've decided should apply to ARM. It's easy to imagine some information-gathering tool that doesn't want to add ARM-specific code-paths just to get some statistics from a binary. Cheers. Tim.
On 13 March 2014 19:13, Tim Northover <t.p.northover at gmail.com> wrote:> I think emitting both is a good thing, personally. It means that > generic tools (and possibly even debuggers, given certain runtime > support) can rely on the DWARF standard, not just the bits we've > decided should apply to ARM.Absolutely! I was actually trying to reduce (or remove) the ARM specific directives and make the EHABI understand the CFI directives, but that would be a IAS-only feature and we'd have to test both all the time (more space for bugs). cheers, --renato
On 13 March 2014 16:48, Keith Walker <Keith.Walker at arm.com> wrote:> It does seem strange if you are only compiling C code you have to specify -fno-exceptions in order to not generated the overhead of the exception tables.Sorry, I should have said "-fno-unwind-tables" here, which does make sense. cheers, --renato
Hi Renato, I would like to know what do you mean by "commoning them up"? I object to the idea to remove (or reduce) the ARM directives in favor of CFI directives, though I believe it will be good to emit *both* ARM directives and CFI directives so that some debugger or profiling tools can be used without implementing ARM-specific logic. The main reason for the objection is the compatibility between the integrated-as and the binutils gas. What if we have to use gas to compile the output of LLVM? Although we are working hard to improve the integrated-as, but there are a lot of existing code simply doesn't work when integrated-as is used. Some of the issues are even considered as a *feature* and marked as won't fix. For the space issue, I personally don't think this is a big issue. For the code without exception handling, only stack informations will be encoded. Besides, the encoding format is very compact. In the common cases, the code without exception handling needs only 8-12 bytes per function. If this is still an issue, then -fno-unwind-table might be a solution (i.e. at llvm assembly level, the function should be marked with nounwind and without uwtable.) Sincerely, Logan On Thu, Mar 13, 2014 at 9:15 PM, Renato Golin <renato.golin at linaro.org>wrote:> Hi Keith, Anton, Logan, > > Last time we spoke about ARM unwinding, we agreed to have both CFI and > directive variants in ARM, so that both EH and debuggers/profilers > could correctly unwind the stack. The problem, obviously, is that we > now have redundant information and I decided to have a go commoning > them up. > > One of the issues, I think, is GNU compatibility (so GAS can generate > the tables correctly when not using the integrated assembler), and it > seems there GCC also emits both EHABI directives and Dwarf, so I don't > think we'll be able to move away from it. Since this is only relevant > in debug/profiling mode, and the only problem is code size, I think > this is something we can live with. Do you guys agree with it? > > Another issue is the usage of EH tables in C code. I believe the > consensus is that it may not be the most optimal for never-exceptional > code, but it's the safest default option. The only thing remaining is > to choose a way to disable them via some flag. As weird as > -fno-exceptions sounds for C code, I think we'll have to go with it. > Any other ideas? > > Finally, Keith, do you have some internal EHABI test you can run Clang > on? Does any one know of a large, self contained code, that makes > heavy use of exceptions? > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140316/023ca15d/attachment.html>
On 15 March 2014 17:06, Logan Chien <tzuhsiang.chien at gmail.com> wrote:> I would like to know what do you mean by "commoning them up"?Hi Logan, That'd be reducing ARM directives in favour of CFI, but as I said (and you too), GNU compatibility will probably be an issue for a very long time.> For the space issue, I personally don't think this is a big issue. For the > code without exception handling, only stack informations will be encoded. > Besides, the encoding format is very compact. In the common cases, the code > without exception handling needs only 8-12 bytes per function. If this is > still an issue, then -fno-unwind-table might be a solution (i.e. at llvm > assembly level, the function should be marked with nounwind and without > uwtable.)Yes, and that's what my merge request implements: http://llvm-reviews.chandlerc.com/D3079 As soon as that's in, I believe EHABI is finally in good shape to be called Beta. Since the 3.4 release I'm trying to get the EHABI and IAS support in good shape (removing the final restraints, testing a lot), for them to be enabled by default in 3.5, and I think we got it, thanks to you, Anton, Saleem and many others. cheers, --renato