JinGu Kang
2014-Dec-08 11:33 UTC
[LLVMdev] Question about '-fno-exceptions' option and 'ExceptionsType' on MCAsmInfo with ARM.
Hi all I have a question about the '-fno-exceptions' option with clang and 'ExceptionsType' on MCAsmInfo. I am looking for a way to avoid generating stack unwinding codes when compiling with the "armv7-none-linux-gnu" triple using clang. I tried the '-fno-exceptions' option in order to do that, but unwinding function symbols like '__aeabi_unwind_cpp_pr0' were still present. I think 'ExceptionType' of MCAsmInfo is set to ExceptionType::ARM with the above target triple and it is not affected by the '-fno-exceptions' option. Am I missing something about this, or do we need to provide an interface to disable generation of exception codes? Thanks, JinGu Kang
Rafael EspĂndola
2014-Dec-08 14:36 UTC
[LLVMdev] [cfe-dev] Question about '-fno-exceptions' option and 'ExceptionsType' on MCAsmInfo with ARM.
On 8 December 2014 at 06:33, JinGu Kang <jingu at codeplay.com> wrote:> Hi all > > I have a question about the '-fno-exceptions' option with clang and > 'ExceptionsType' on MCAsmInfo. > > I am looking for a way to avoid generating stack unwinding codes when > compiling with the "armv7-none-linux-gnu" triple using clang. I tried the > '-fno-exceptions' option in order to do that, but unwinding function symbols > like '__aeabi_unwind_cpp_pr0' were still present. I think 'ExceptionType' of > MCAsmInfo is set to ExceptionType::ARM with the above target triple and it > is not affected by the '-fno-exceptions' option. Am I missing something > about this, or do we need to provide an interface to disable generation of > exception codes?At the MC layer I think we just have a bad name. The flag actually controls what unwind table format is used. Those are used for exceptions, but also have other uses. At least for x86_64 and the .eh_frame section, you can exclude a function by not including the uwtable attribute. At the clang level that is done with the -fno-asynchronous-unwind-tables option. Cheers, Rafael
JinGu Kang
2014-Dec-08 16:20 UTC
[LLVMdev] [cfe-dev] Question about '-fno-exceptions' option and 'ExceptionsType' on MCAsmInfo with ARM.
Hi Rafael, Thanks for your response. I feel I need to learn ARM's unwind table's mechanism first. I saw ARM backend checks uwtable attribute and it generates '.cantunwind' directive, sets CantUnwind variable and etc... but it does not seems to avoid generation of the table. If someone knows it well, please guide me. Thanks, JinGu Kang On 12/08/2014 02:36 PM, Rafael EspĂndola wrote:> On 8 December 2014 at 06:33, JinGu Kang <jingu at codeplay.com> wrote: >> Hi all >> >> I have a question about the '-fno-exceptions' option with clang and >> 'ExceptionsType' on MCAsmInfo. >> >> I am looking for a way to avoid generating stack unwinding codes when >> compiling with the "armv7-none-linux-gnu" triple using clang. I tried the >> '-fno-exceptions' option in order to do that, but unwinding function symbols >> like '__aeabi_unwind_cpp_pr0' were still present. I think 'ExceptionType' of >> MCAsmInfo is set to ExceptionType::ARM with the above target triple and it >> is not affected by the '-fno-exceptions' option. Am I missing something >> about this, or do we need to provide an interface to disable generation of >> exception codes? > At the MC layer I think we just have a bad name. The flag actually > controls what unwind table format is used. Those are used for > exceptions, but also have other uses. > > At least for x86_64 and the .eh_frame section, you can exclude a > function by not including the uwtable attribute. At the clang level > that is done with the -fno-asynchronous-unwind-tables option. > > Cheers, > Rafael
Possibly Parallel Threads
- [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
- [LLVMdev] typeinfo for llvm::MCAsmInfo is missing
- [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo
- [LLVMdev] typeinfo for llvm::MCAsmInfo is missing
- [LLVMdev] typeinfo for llvm::MCAsmInfo is missing