similar to: Require support to use LLVM's PDB classes and pdbutil

I'd start with reading the documentation about PDB file format, described here: https://llvm.org/docs/PDB/index.html There's a lot there, but if you want to interpret the contents on your own (even using LLVM's PDB libraries to do the low level work) you're going to need to understand it. Once you have a basic understanding of what goes into a PDB file and how it's

The merge feature was implemented primarily for testing but was never really productionized, so your guess about what the underlying problem is sounds correct to me. We could probably hide the subcommand so users don’t accidentally use it, or if someone wants to properly implement the missing features, that would be even better On Sat, Dec 22, 2018 at 10:48 AM Vivien Millet via llvm-dev <

Yes I am the person who wrote this feature (along with most other PDB-related features). I thought about some and I think it's a bit hard (if not impossible) to merge PDBs in this way. Here's a short list of things I came up with 1) We need to merge the list of modules. This requires first detecting if two modules are actually the same. For example, if I run llvm-pdbutil on a random

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

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

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

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

Hello, Is anyone working on implementing DebugInfo/PDB that doesn't depend on DIA? What would it take to have minimal implementation that would allow to take a PDB file and look up symbols using llvm-symbolizer on a non-Windows (e.g. Linux or MacOS) platform? Regards, Dmitri -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

When trying to merge 2 pdbs which have each their own DBI stream, I endup with a pdb with an inconsistent number of stream and no DBI stream (or at least not at fixed index 3, producing a corrupt error when dumping with -l). Looking at the code, it seems that we don't merge other streams than TPI and IPI streams, am I right ? Is the "merge" feature completely implemented ? Thanks

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

(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

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

Hi, We are starting to test binaries generated by lld on windows and we notices that sometimes the visual studio debugger can't see the content of variables or gets the call stack wrong for deeply nested or complex types. Did anyone else have the same problems, or any way to try to figure out what is missing? I tried llvm-pdbutil dump -symbols but there is a lot of small diferences on

Hi Zach (or anyone else who may have a clue), I'm currently investigating making use of LLVM for PDB parsing for with a view to supporting partial PDBs as produced by /DEBUG:FASTLINK as the VS DIA SDK hasn't been updated to handle them. I know this is probably low on your priority list but since /DEBUG:FASTLINK is now the implied default for VS2017 I figure it's a good time to take a

I've just started using the llvm-pdbutil tool. Great job on the general tool. But I'm having trouble figuring out how the output of the dump tool relates to real addresses in memory or for that matter relative virtual address either. Here's the logic I tried (which doesn't work): (1) Get Instruction Pointer of interest (2) Subtract the base address of the dll that address

On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> wrote: > Hi, > > No I didn't, I used cl.exe from the visual studio toolchain. What I'm > proposing is a tool for processing .obj files in COFF format, reading them > and generating the GHASH part. > > To make our build faster we use hundreds of unity build files (.cpp's with > a

Hello Rui, We meet an LLD PDB issue that if we link assembly code with C code and set >= -O1 level optimization in LTO, the executable's PDB will contain wrong zero Lines for the assembly code in DEBUG_S_LINES subsection, and then our COFF source debuggers will fail to do the source-level debug on the executable. This issue is same in both Linux and Windows, and I figure out a simple case

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic