search for: pdbutil

Hi All, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have looked into tools/llvm-pdbutil, and “ninja llvm-pdbutil-fuzzer” does not build at all, and the error refers to non-existent headers. The last update to the codebase is reasonably recent, and was done in June 2017. Is anyone using it? Thus I am not sure what should be done with this. I think we should either: a) Move “tools/llv...

...kov <ekarpenkov at apple.com> > wrote: > >> Hi All, >> >> As a part of a recent move of libFuzzer from LLVM to compiler-rt I am >> looking into updating the build code >> for the libraries which use libFuzzer. >> >> I have looked into tools/llvm-pdbutil, and “ninja llvm-pdbutil-fuzzer” >> does not build at all, >> and the error refers to non-existent headers. >> The last update to the codebase is reasonably recent, and was done in >> June 2017. >> Is anyone using it? >> >> Thus I am not sure what should be...

Hello, I'm trying to parse debug information out of PDB files that's created by visual studio, and also maybe producing stacktrace on linux. Does anyone has leads to how I can do that with LLVM's pdbutil? Or point me to a documentation about that? Thanks. Experian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190515/1de208d5/attachment-0001.html>

...(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 organized, LLVM's PDB APIs should (hopefully) be fairly self-explanatory and you can read the code of llvm-pdbutil to see how it does various things, which you can copy. On Wed, May 15, 2019 at 4:35 PM Reid Kleckner <rnk at google.com> wrote: > I would say that llvm-pdbutil mainly exists to dump PDBs as human readable > text, and to translate them to and from YAML. As far as interpreting the >...

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 describe it. Anyway I could start trying to > do it in my jit compiler and then, once I get something working (if that > happens :)), i can come...

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

...> >> 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 describe it. Anyway I could start trying to >>> do it in my jit compiler and then, once I get something working (if that >&...

...appy 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 describe it. Anyway I could start trying to >>>>> do it in my jit compiler and then, once I get somethin...

...me once all your code is jitted, and when the debugger tries to look up that symbol, it finds a record that tells it to go check the other PDB file. So, here are the things I think you would need to do: 1) Create a JIT module in the module list with a unique name. All symbols will go here. llvm-pdbutil dump -modules shows you the list. Be careful about putting it at the end though, because there's already one at the end called * LINKER * that is kind of special. On the other hand, you don't want to put it first because it means you will have to do lots of fixups on the EXE PDB. It'...

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 <

...Context just after llvm::object::ObjectFile is emitted by the JIT engine and complete the EXE PDB I had rebuilt with PDBFileBuilder. Does it sounds a good bet to you ? If I succeed doing that I think that could be a good extension to the debugging possibilities of MCJit if not being an extension to pdbutil. Le jeu. 17 janv. 2019 à 19:37, Zachary Turner <zturner at google.com> a écrit : > Well, for example the TPI stream is just one big collection of types. > Presumably your JIT code will reuse some of the same types (perhaps, > std::string for example) as your non-jitted code. Your...

...eatures). 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 PDB on my disk, I get this (output is trimmed for brevity) $ llvm-pdbutil.exe dump -modules bin\not.pdb Modules ============================================================ Mod 0000 | `D:\src\llvmbuild\cl\Debug\x64\utils\not\CMakeFiles\not.dir\not.cpp.obj`:...

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

For the first and third questions, the easiest thing to do would be run llvm-pdbutil under a debugger and step through the code. Code that looks simple and innocuous can often have a lot of stuff hidden behind it. For example you could step through that loop that iterates the debug subsections and look at the value of Reader.getOffset() every time, and see if it matches with your o...

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

...ectFile is emitted by >> the JIT engine and complete the EXE PDB I had rebuilt with PDBFileBuilder. >> Does it sounds a good bet to you ? If I succeed doing that I think that >> could be a good extension to the debugging possibilities of MCJit if not >> being an extension to pdbutil. >> >> Le jeu. 17 janv. 2019 à 19:37, Zachary Turner <zturner at google.com> a >> écrit : >> >>> Well, for example the TPI stream is just one big collection of types. >>> Presumably your JIT code will reuse some of the same types (perhaps, >>&gt...

...ce and then discover for each address, its module, function, source index, line, and column. I still have a couple of loose ends though. Do you know what's going on here? 1. There appears to be 8 bytes before every LineFragmentHeader. Here's some of my own debug output, which matches llvm-pdbutil's output. You can see it says "unknown bytes: ...". read C13 line info 136720 bytes unknown bytes: f2 00 00 00 60 00 00 00 LineFragmentHeader{ .RelocOffset = 0, .RelocSegment = 5, .Flags = LineFlags{ .LF_HaveColumns = true, .unused = 0 }, .CodeSize = 52 } has column: true LineBlockF...

...it is a checksum for, and that refers to the string table. However, > it's possible for certain symbol records to refer to the string table too. > See lld/COFF/PDB.cpp and Ctrl+F for "PDBStrTab" and you will find some > information about this. > > 2) When you run `llvm-pdbutil dump -streams` on the copied PDB, do all of > them show a reasonable description? Are there any streams that say (???)? > If so, that's a problem. > > > does visual studio will consider a symbol file broken if the address > goes beyond the official module address range (the c...

I will build LLVM locally, debug and report back. On Sat, Mar 3, 2018 at 2:47 AM, Hayden Livingston <halivingston at gmail.com> wrote: > 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...

...the string table. >>> However, it's possible for certain symbol records to refer to the string >>> table too. See lld/COFF/PDB.cpp and Ctrl+F for "PDBStrTab" and you will >>> find some information about this. >>> >>> 2) When you run `llvm-pdbutil dump -streams` on the copied PDB, do all >>> of them show a reasonable description? Are there any streams that say >>> (???)? If so, that's a problem. >>> >>> > does visual studio will consider a symbol file broken if the address >>> goes beyond...