similar to: [LLVMdev] DebugIR pass fails with an assert

Looks like a bug in the DebugIR pass. I imagine that without the -debug–ir flag, you will be able to get a little further. Nonetheless, can you send me the "bitcodetestqtapp" that you're running, or steps to reproduce? I'd love to take a look. Thanks, Dan From: Shailesh Kumar <shaileshkumar41 at yahoo.com<mailto:shaileshkumar41 at yahoo.com>> Reply-To: Shailesh

Hi,  I am trying to run a simple qt 5 application compiled to bitcode on OS X. I am getting the following error. I have modified lli to load qt libraries. When I use with option mcjit, I get the following error lli -use-mcjit -debug-ir bitcodetestqtapp Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file

Hello all, I recently felt the need to have debug info at the LLVM IR level (because my frontend's semantics vastly differ from IR that it doesn't make much sense to use it). Asm can sometimes be too "low level", so it's nice to have the ability to single-step at the IR level. The pass that used to do this (-debugir) bitrotted and was removed from tree. I spent the weekend

Hi, I recently had the need to see the correspondence between some Clang generated LLVM IR and the compiled machine code within a debugger (lldb in this case). Unfortunately it looks like the functionality to do this used to be in a pass called 'DebugIR' but was removed due to the lack of a maintainer [1]. It appears an attempt was made [2] to revive this but it appears to have stalled.

On Fri, Mar 25, 2016 at 12:45 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 03/25/2016 03:28 AM, Philip Reames via llvm-dev wrote: >> >> I've scanned over your proposal, but am not quite sure I understand your >> objective. Is your intent to be able to step through IR source in a >> debugger and inspect intermediate state? Yes, that is what I had in

You can attach debug info to the Llvm module about LLVM IR, at which point one can throw the executable into any debugger and get llvm level debugging. I've started a patch to revive this feature (DebugIR pass). I've been sidetracked the past month, but I'll come back to it soon :) https://reviews.llvm.org/D40778 Cheers, Siddharth On Thu 4 Jan, 2018, 09:23 Brenda So via llvm-dev,

Hi Dan, Having missed this functionality myself in the past I’m excited to see this gain traction. Let me know if there’s anything I can do to help this along. Cheers, Jonas On Wed, 21 Mar 2018 at 18:19, Dan Liew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > I recently had the need to see the correspondence between some Clang > generated LLVM IR and the compiled

On 3/25/16 11:58 AM, Janek van Oirschot via llvm-dev wrote: > On Fri, Mar 25, 2016 at 12:45 PM, Tobias Grosser <tobias at grosser.es> wrote: >> On 03/25/2016 03:28 AM, Philip Reames via llvm-dev wrote: >>> >>> I've scanned over your proposal, but am not quite sure I understand your >>> objective. Is your intent to be able to step through IR source in

We have implemented a debug pass to enable debugging of jitted functions. The pass dumps the IR of the module at the beginning of the pass, which then becomes the source code for the debug metadata. Our solution focuses on a windows x86 solution but I’m sure it would be easy to extend to other platforms. In order to load the resulting debugging info into Visual Studio, we jit to object file then

Hi I know that LLVM provide some debug API for us to know the source code information. For example, every IR instruction's source line number and column number. However, are there any method to get a mapping from IR instruction to binary address directly. I don't want to use dwarf line mapping table as a bridge. I think the binary is generated by clang and llvm. I think there definitely

On 03/25/2016 03:28 AM, Philip Reames via llvm-dev wrote: > I've scanned over your proposal, but am not quite sure I understand your > objective. Is your intent to be able to step through IR source in a > debugger and inspect intermediate state? If so, you may consider > whether "simply" inserting debug metatadata into your IR which describes > the IR source, and

Thanks for responding, Duncan, and clarifying that y'all need more info to help. I'm trying to compile binaries on os x 10.5.8 intel hardware that are compatible on ppc os x 10.4. When I include various flags to llvm-gcc, including: -m32 -arch ppc -isysroot /Developer/SDKs/MacOS10.4u.sdk -mmacosx-version-min=10.4 I am seeing errors when compiling using llvm-gcc 4.2. If I leave out

Hi I am looking at open projects that LLVM want to implement and it seems to be a suggestion to write an LLVM IR level debugger. Is there any existing LLVM projects out there that already does such a thing? If not, I would like to try implementing one myself. By debugger, I think it means something like gdb, where you can insert breakpoints, run code and observe layout of registers and memory at

+ 1 to having this functionality implemented as `llvm-as -g` or some analog (`clang -g foo.ll`). As I outlined in https://reviews.llvm.org/D40778 <https://reviews.llvm.org/D40778>, I think such a solution can be made to work for JIT users who don't have on-disk *.ll files. > On Mar 21, 2018, at 5:37 PM, Jason Surprise via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >

I've also tried the next combination: true, // ForceInterpreter false, // UseMCJIT and ios app just crashed with no output 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hey. > > I've checked out LLVM/Clang 3.5 and modified my static libs source code to > use the latest llvm/clang sources. > Also i'm trying triple

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mon, Dec 16, 2019 at 03:58:29PM +0100, Pino Toscano wrote: > Use the newer copy shipped locally as 3rdparty, instead of the one in > the common submodule, as the latter copy will go away soon. > --- > .gitignore | 2 ++ > Makefile.am | 2 +- > configure.ac | 2 +- > test-harness/Makefile.am | 2 +- > v2v/Makefile.am | 4

Hi, Lang. Thanks for clarification. I will check out current branch tomorrow and report you back. Most likely i will create bug issue with cleaned sources for static lib and test ios app. Actually i'm not professional c++ dev so my question is - is there any chance to do the next: 1. compile .cpp code to .ll code (seems i already did it) 2. interpret .ll file by any supported at the moment

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx