search for: dwarfcfiexcept

...tifier() is meant to be used? Am I atleast passing this > Simple bool around correctly, and appending " simple" in the low asm > layer appropriately? What am I missing? > > Thanks. > > include/llvm/MC/MCStreamer.h | 2 +- > lib/CodeGen/AsmPrinter/DwarfCFIException.cpp | 2 +- > lib/MC/MCAsmStreamer.cpp | 6 ++++-- > lib/MC/MCParser/AsmParser.cpp | 8 ++++++-- > lib/MC/MCStreamer.cpp | 2 +- > test/MC/AsmParser/cfi-startproc-simple.s | 7 +++++++ > 6 files changed, 20 insertions(+...

...should only be emitted if -fno-unwind-tables is chosen AND the function can't unwind. Also, do not assume that EHABI behaviour in LLVM is currently correct, especially related to uwtable and nounwind. Those were made with the x86_64's ABI in mind, and have only interoperated seriously with DwarfCFIException until very recently. There has to be a way to disable unwind tables, so either the "no attribute" behaviour above is wrong or we need a new attribute "noehtable". There has to be a way to emit CantUnwind, so if the behaviour above is right, the "uwtables" attribut...

> I disagree on this. Table emission by itself doesn't involve code > generation and I don't think it makes sense as a per function attribute > either. You either want it for all functions or only when needed (e.g. > exceptions are possible). As such, it makes perfect sense to me as a > global flag. It has to be an attribute because of LTO. You can LTO a file compiled with

...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, A...

...nt 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 exce...

Hi. I'm very new to LLVM. For reasons to do with custom exception handling, we have a need to check IP/PC at runtime against code ranges. This can encompass multiple logically adjacent blocks. How to do this? I'm guessing:   insert a label at end of every block, takes it address, store that somewhere in our data; preferably as an offset from module or function start, but full address

...; 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 in...

...gers can also use this table to unwind the stack. ** Exception Handling ** LLVM has four types of EH: Dwarf, ARM, SjLj and Win64. Of them, only SjLj doesn't need unwind tables, and each of the others, even being Itanium-compatible, need slightly different logic. In LLVM, all targets that use DwarfCFIException are using the same tables as the debugger and profilers would, but ARM and Win64 have separate unwind logic. This is where the problem begins. We're left with three EH types: 1. No tables (SjLj) 2. Dwarf tables (DwarfCFI) 3. Specific EH tables (ARM, Win64?) ** Debug & Profiling ** In...

...-fno-asynchronous-unwind-tables. That is why we have the uwtable >> attribute. > > Hi Rafael, > > I've removed the -arm-disable-ehabi flag already, and I'm planning on > using the uwtable attribute to determine if we need to emit the unwind > tables or not, just like DwarfCFIException. What is the real semantics > of uwtable? Just that: unwind tables are output for the function, even if nothing else seems to say they are necessary. > I don't see that attribute too often, but I still see tables being > emitted in x86_64. Strange. I see it even with simple C tes...

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

...g directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Transforms/InstCombine' llvm[3]: Compiling InstCombineAddSub.cpp for Release+Asserts build llvm[3]: Compiling LoopRerollPass.cpp for Release+Asserts build llvm[3]: Compiling X86SelectionDAGInfo.cpp for Release+Asserts build llvm[3]: Compiling DwarfCFIException.cpp for Release+Asserts build llvm[3]: Compiling InstCombineAndOrXor.cpp for Release+Asserts build llvm[3]: Compiling X86Subtarget.cpp for Release+Asserts build llvm[3]: Compiling LoopRotation.cpp for Release+Asserts build llvm[3]: Compiling DwarfCompileUnit.cpp for Release+Asserts build llvm[3]...