similar to: [MCJIT] messy call stack debug on x64 code in VisualStudio

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

Hi Paul, How can i make this call to intrinsic from the c++ code ? I'm not working with the IR language, but directly in C++ with IRBuilder::CreateAlloca. My goal is that one : - Generate machine code with an instance of the class 'IRBuilder' - Emit 'ObjFile' class instance with MCJIT - Create a DwarfContext instance directly from the emitted ObjFile object

Hi, First, considering I'm using an IRBuilder and a DIBuilder to build my program, how can I automatically bind the CreateAlloca with my named local variable inside the DIBuilder ? Is it automatic with the Twine name of CreateAlloca ? And/Or should I use DIBuilder::createAutoVariable and how ? Then, I'm wondering how to locate back my local variable in memory (register or stack) once i

Hi Lang, That would be great ! :) For now I found a hack which consist of loading a "full of NOP" DLL, use my own DllMemMgr which allocates JIT sections inside the DLL virtual space, backup the memory inside some buffers, unload the DLL, copy the buffer inside the DLL file, create the PDB, reload the DLL file which hopefully in 99% is reloaded at the same virtual address (this allow me

"IR" often refers to the general concept/semantics, not only the textual format in .ll files (there are 3 main forms - bitcode, textual IR, and the in-memory representation (llvm::Module, etc - constructed using IRBuilder)). A great place to start is to look at what Clang does to produce debug info - it uses IRBuilder, for instance. So you could look at how Clang uses the IRBuilder when

Binding the alloca to the debug-info metadata is not automatic. You need to emit an intrinsic function call to llvm.dbg.declare to bind the two together. If you are simply trying to emit DWARF for your program, the rest of the processing should already be in place for that. If you are trying to do something else, you would need to describe that so we understand what you need. --paulr From:

That’s a good question, by default when emitting the object file I choose COFF but it embeds dwarf and not codeview in the end.. there probably is a way to do it or at least it must be implemented if not yet.. Lets imagine I manage to do that.. when you say there is nothing to do, I still must have a PDBFileBuilder to copy the codeview data inside the EXE PDB right ? I cannot insert them easily in

Hi Zachary ! If there a way to easily create a new PDBFileBuilder from an existing PDBFile or can/should I do the translation myself ? I would like to start from a builder filled with the EXE PDB data and then complete its DBI stream with the JIT module/symbols. Thanks ! Le mer. 16 janv. 2019 à 23:41, Vivien Millet <vivien.millet at gmail.com> a écrit : > Thank you Zachary ! > I

Ok I see.. what do you mean by “making sure to de-duplicate records as necessary” ? Le jeu. 17 janv. 2019 à 19:09, Zachary Turner <zturner at google.com> a écrit : > It's possible in theory to support incremental updates to a PDB (the file > format is designed specifically with that in mind). But this functionality > was never added to the PDB library since lld doesn't

Ok I understand more what you meant. In fact I don’t care about the pdb size, at least as a first step, so it won’t be a problem for me to have duplicated symbols. Concerning TypeIndices my plan if possible is not to generate a pdb for my jit and merge it, but instead directly extract debug info from a DwarfContext just after llvm::object::ObjectFile is emitted by the JIT engine and complete the

Hello Zachary, Sorry for replying so lately but It's been a week I'm thinking an working hard on your "dll memory buffer" idea to see if it works and give you feedbacks ! And it works pretty well until now : I shared on the list what I did : - create a .ASM file full of "int 3" instructions (to ensure that if we execute over the boundaries we instantly break. -

(Yes you are right this is my fault) Considering the string table, it only seems to contains file relative informations in every pdb I am using, and it looks correct but I will check it. I looked at the pdb.cpp code about checksums and tables, I copied some stuff and got things wrong according to cvdump, then I simplified the process of copying the table and it worked (in cvdump it finds the file

Sure. Along the way I’m happy to answer any specific questions you might have too even if it’s for your downstream project On Wed, Jan 16, 2019 at 1:38 PM Vivien Millet <vivien.millet at gmail.com> wrote: > I would be up to improve pdbutil but I doubt I have enough knowledge or > time to provide the complete merge feature, it would still be a very > specific kind of merge as you

Well, that’s certainly possible, but improving llvm-pdbutil is another possibility. Doing it directly in your jit compiler will probably save you time though, since you won’t have to worry about writing tests and going through code review On Wed, Jan 16, 2019 at 1:01 PM Vivien Millet <vivien.millet at gmail.com> wrote: > Thanks for the tips ! > When you talk about doing all of this I

On Fri, Mar 9, 2018 at 7:00 PM Lang Hames <lhames at gmail.com> wrote: > Hi Vivien, > > I'm not familiar with Windows development, but I believe you could dump > the object file to disk then run LINK.EXE to produce the PDB. > Alternatively, I think LLD can also produce PDB files (Rui -- is that > right?), in which case you may be able to use that. > Yes, lld can

Sorry I meant 0xE8, 0xFF was in my head because of disassembling and seeing it in use, my bad. Ok I didn't thought about PIC, that's a good idea ! ... I forgot it existed at the wrong moment I guess ... How can I modify the GOT then ? Is there an api somewhere in the execution engine / MCJIT ? Or is it somewhere else ? Or I need to accept the idea of hacking stuff inside the LLVM code

Hi, thanks for the answers, i tried to use LINK.EXE to produce a pdb, but unfortunately, it produces an empty pdb (i have debug symbols in the dumped .obj because I can see them with PEViewer). It is probably because i have undefined symbols, which is logical because i'm dumping machine code which points to running native code. I still dont understand why LINK.EXE is not able to produce a

I'm sorry but I don't think I understand the question. But if you can't produce a pdb using MSVC, it is hard to imagine that only lld can do, unless MSVC linker has a bug. On Wed, Mar 14, 2018 at 3:07 PM Vivien Millet <vivien.millet at gmail.com> wrote: > Hi, thanks for the answers, i tried to use LINK.EXE to produce a pdb, but > unfortunately, it produces an empty pdb

Is it possible to write a .pdb file containing the debug info stored in a COFFObjectFile once the NotifyObjectEmitted is triggered by the JIT compiler ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180308/3c25cddd/attachment.html>

On Tue, Jan 15, 2019 at 2:50 AM Vivien Millet <vivien.millet at gmail.com> wrote: > Hello Zachary ! > Thanks for your time ! > So you are one of the happy guys who suffered from the lack of PDB format > information :) > Yes, that would be me :) > To be honest I'm really a beginner in the PDB stuff, I just read some llvm > documentation to understand what went