Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang: warning: argument unused during compilation: '-mtriple=arm-none-eabi' The IR triple is "x86_64-unknown-linux-gnu". Is there a way I can force the triple? Then I compiled with llc: $ llc -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.clang.ll -o exception.clang.s It doesn't generate the tables because ARMELFMCAsmInfo doesn't set ExceptionsType. If I set it to Dwarf and fix the missing lowering operations (EXCEPTIONADDR and EHSELECTION), it does generate a table which is slightly different than what GCC is doing. I've compared the assembly generated and it's close, but not perfect. Some EABI issues (frame pointer, some intrinsics mismatch, EH call table) were present, but the general execution flow seems very similar. If I compile the resulting asm with GCC ("-T generic-hosted.ld") and run, it breaks completely. GCC's run flawlessly. Anyone has any idea on the status of exception handling in clang/LLVM? DwarfException cannot be easily overwritten, and adding target specific code to it seems wrong... Attached is my example compiled with Codesourcery's GCC (2009q3) and clang (2.7). cheers, --renato -------------- next part -------------- A non-text attachment was scrubbed... Name: exception-clang-example.tar.gz Type: application/x-compressed-tar Size: 9630 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100517/ba3d2692/attachment.bin>
Hello, Renato> Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong...Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On May 17, 2010, at 10:38 AM, Anton Korobeynikov wrote:> Hello, Renato > >> Anyone has any idea on the status of exception handling in clang/LLVM? >> DwarfException cannot be easily overwritten, and adding target specific >> code to it seems wrong... > Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, > sjlj excheptions on arm/darwin). I have some patched uncommitted for > EH on ARM but they are too far from being complete. >We do support SJLJ exceptions on ARM for Darwin at least. -bw
> -----Original Message----- > From: Anton Korobeynikov [mailto:anton at korobeynikov.info] > > Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, > sjlj excheptions on arm/darwin). I have some patched uncommitted for > EH on ARM but they are too far from being complete.Hi Anton, Are you actively working in that area? I did some experiments and managed to understand how LLVM does the exception handling, but my changes are also far from working. My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). To change that in line with AsmWriter would be a major change and passing a ARMException reference through AsmWriter would pass the object through many places that are not concerned with it. A simple registration mechanism (DE->registerTargetCode-thingy) would be the least change and more direct approach, but it's damn ugly. ;) Apart from that, the format of the table and the calls to intrinsic functions are quite close. About Sj/Lj exceptions, that's not ARM EHABI compliant. EABI GCC won't compile that, I guess. Not to mention it hampers normal execution... Thanks, --renato -- 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.