search for: beginfunct

> 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

...r the pointer. I am unfortunately running into llc problems with this pass. I did *opt -debug-ir hello.bc -o hello.deb.bc* *llc -march=arm -debug -O0 hello.deb.bc -o hello.deb.s* This is aborting with the error: llc: llvm-3.4/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1614: void llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. I'm assuming this is because llc found some errors in the metadata that debug-ir prints out. How do I find and correct this? Thanks again, Shruti On Sat, May 17, 2014 at 5:57...

...;> I did >> *opt -debug-ir hello.bc -o hello.deb.bc* >> >> *llc -march=arm -debug -O0 hello.deb.bc -o hello.deb.s* >> >> >> This is aborting with the error: llc: >> llvm-3.4/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1614: void >> llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion >> `TheCU && "Unable to find compile unit!"' failed. >> I'm assuming this is because llc found some errors in the metadata that >> debug-ir prints out. How do I find and correct this? > > > This is inde...

...ion of LLVM with asserts enabled (I.e. A debug build)? I cut-and-paste your IR into a text file and ran (a debug version of) llc on it, which caused the following assertion failure that seems related to some DWARF mishap: llc: ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1400: void llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. 0 llc 0x00000000011d3ad6 1 llc 0x00000000011d3d5d 2 llc 0x00000000011d37ac 3 libpthread.so.0 0x00007fa2aa6a7cb0 4 libc.so.6 0x00007fa2a9...

...;> I did >> *opt -debug-ir hello.bc -o hello.deb.bc* >> >> *llc -march=arm -debug -O0 hello.deb.bc -o hello.deb.s* >> >> >> This is aborting with the error: llc: >> llvm-3.4/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1614: void >> llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion >> `TheCU && "Unable to find compile unit!"' failed. >> I'm assuming this is because llc found some errors in the metadata that >> debug-ir prints out. How do I find and correct this? >> > > This is...

...* >> >> >> >> *llc -march=arm -debug -O0 hello.deb.bc -o hello.deb.s* >> >> >> >> >> >> This is aborting with the error: llc: >> >> llvm-3.4/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1614: void >> >> llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): >> >> Assertion >> >> `TheCU && "Unable to find compile unit!"' failed. >> >> I'm assuming this is because llc found some errors in the metadata that >> >> debug-ir prints out. How do I find...

...t; 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 testcases: void bar(void); void zed(void) { bar();} produces define void @zed() #0 .... attributes #0 = { nounwind uwtable... >The rules on what to emit in beginFunction() are a > bit convoluted, and I guess that's because uwtables' semantics is not > definite. I was hoping for something a bit stronger, because we do > lose a lot of information in the back-end, such as what exception > style is has (depending on the target, language, flags)....

...etc. The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): > Assertion failed: (TheCU && "Unable to find compile unit!"), function beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. > 0 clang-3.4 0x0000000103ff3808 llvm::sys::PrintStackTrace(__sFILE*) + 40 > 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 > 2 libsystem_platform.dylib 0x00007fff8dd185aa _sigtramp + 26...

...(a debug version of) >>> llc >>> on it, which caused the following assertion failure that seems related >>> to >>> some DWARF mishap: >>> >>> >>> llc: ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1400: void >>> llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion >>> `TheCU && "Unable to find compile unit!"' failed. >>> 0 llc 0x00000000011d3ad6 >>> 1 llc 0x00000000011d3d5d >>> 2 llc 0x00000000011d37ac >>> 3 l...

I didn't make it clear that I load my Common Lisp application into "lldb" and then load a compiled bundle into my application using dlopen (I'm on OS X and I'm generating a kind of shared library called a "bundle"). Once everything is loaded, the functions from the bundle are accessible to my Common Lisp environment but I don't seem to be able to access the

Hey folks, I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. I can list source lines using "l -f

...t;> llc >>>> on it, which caused the following assertion failure that seems related >>>> to >>>> some DWARF mishap: >>>> >>>> >>>> llc: ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1400: void >>>> llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion >>>> `TheCU && "Unable to find compile unit!"' failed. >>>> 0 llc 0x00000000011d3ad6 >>>> 1 llc 0x00000000011d3d5d >>>> 2 llc 0x00000000011d37ac &...

...e LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): > >> Assertion failed: (TheCU && "Unable to find compile unit!"), function beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. >> 0 clang-3.4 0x0000000103ff3808 llvm::sys::PrintStackTrace(__sFILE*) + 40 >> 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 >> 2 libsystem_platform.dylib 0x00007fff8dd185aa _s...

...passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): >> >>> Assertion failed: (TheCU && "Unable to find compile unit!"), function beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. >>> 0 clang-3.4 0x0000000103ff3808 llvm::sys::PrintStackTrace(__sFILE*) + 40 >>> 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 >>> 2 libsystem_platform.dylib 0x00007ff...

...s for functions. This appears to be to work around problems with gdb. However, I observe is_stmt is not always applied to line entries for functions. This may only affect the arm backend. Compiling the same code with the aarch64 backend does not demonstrate this problem. It seems that DwarfDebug::beginFunction always generates a line table entry with is_stmt for each function. Later, in DwarfDebug::beginInstruction, we create more line table entries. If we have an instruction in a function which: 1) Is associated with the line number of the beginning of the function 2) Comes before the end of the pro...

...but when I have debug symbols enabled >> (“-g”), I get the following error when Clang generates the Dwarf info (using >> a very recent build of LLVM/Clang from Git mirror): >> >> Assertion failed: (TheCU && "Unable to find compile unit!"), function >> beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. >> 0 clang-3.4 0x0000000103ff3808 >> llvm::sys::PrintStackTrace(__sFILE*) + 40 >> 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 >> 2 libsystem_platform.dylib 0x00007fff8d...

...asses the verifier, but when I have debug symbols enabled > (“-g”), I get the following error when Clang generates the Dwarf info (using > a very recent build of LLVM/Clang from Git mirror): > > Assertion failed: (TheCU && "Unable to find compile unit!"), function > beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. > 0 clang-3.4 0x0000000103ff3808 > llvm::sys::PrintStackTrace(__sFILE*) + 40 > 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 > 2 libsystem_platform.dylib 0x00007fff8dd185aa _sigtramp...

Hi, Is there a way to associate LLVM IR instructions with the instructions they finally generate in the assembly file emitted by LLC? I need to track the PC's corresponding to certain IR level instructions for ARM. One way to do this is to tag an IR instruction with a special flag and pass that flag onto the Machine IR created by LLC and then onto Machine Code. It would be helpful if I could

...symbols enabled >>> (“-g”), I get the following error when Clang generates the Dwarf info (using >>> a very recent build of LLVM/Clang from Git mirror): >>> >>> Assertion failed: (TheCU && "Unable to find compile unit!"), function >>> beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. >>> 0 clang-3.4 0x0000000103ff3808 >>> llvm::sys::PrintStackTrace(__sFILE*) + 40 >>> 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 >>> 2 libsystem_platform.dy...

...iff --git a/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp b/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp > index fec5ced..13f5fc3 100644 > --- a/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp > +++ b/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp > @@ -113,7 +113,7 @@ void DwarfCFIException::BeginFunction(const MachineFunction *MF) { > if (!shouldEmitPersonality && !shouldEmitMoves) > return; > > - Asm->OutStreamer.EmitCFIStartProc(); > + Asm->OutStreamer.EmitCFIStartProc(false); > > // Indicate personality routine, if any. > if (!shouldEmitPe...