similar to: LLVM Documentation - How does it get updated?

On 13 December 2016 at 17:45, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Over a month ago I submitted some patches to begin documenting PDB file > format. These files are in llvm/docs/PDB. When I view the docs online > though, they appear stale. Many of the pages are blank, containing only a > file header. This matches up with my initial commit of the

Yes when I first committed the docs were fine upstream. I think I even got 1 or 2 additional commits that I could see the changes of reflected on the website. At some point though, it just stopped updating (I don't know which exact CL). I can find a date range of when things stopped being update if that would be helpful. If I look at the PDB documentation now (which is rooted here

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

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

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

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

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

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

I actually regret doing all caps for PDB, and there seems to be mixed use of all caps / rolling caps even with dwarf (some places say DWARF, others say Dwarf). I don't feel too strongly aside from the minor inconvenience of having to change thousands of occurrences where I already used rolling caps though :-/ On Fri, Jul 22, 2016 at 10:52 AM Reid Kleckner <rnk at google.com> wrote:

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

Did you change both the compiler and linker (or make sure that your objcopy was updated to write your 64 bit hashes)? The linker is hardcodes to expect 20-byte sha 1s , anything else and it will recompute them in serial On Tue, Jan 30, 2018 at 12:28 PM Leonardo Santagada <santagada at gmail.com> wrote: > Nice and why are you trying blake2 instead of a faster hash algorithm? And > do

So I found all 20 bytes and changed then to GHASH_SIZE (a const I defined in typehashing.h) and finished the switch to xxHash64, that saved me around 50 seconds to 56s, then I changed it to uint64_t instead of a 8 byte uint_8 array and that gave me 48s. With release config and a pgo pass I'm now linking in 38s... so faster than link.exe in vs 2017 (which is faster than vs 2015) doing fastlink.

See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. Does

Uhmm I changed only type hashing... Ok back to trying it again. Let's me find where it is looking at 20 bytes instead of using the size of global type hash. On 30 Jan 2018 21:33, "Zachary Turner" <zturner at google.com> wrote: > Did you change both the compiler and linker (or make sure that your > objcopy was updated to write your 64 bit hashes)? > > The linker is

The quickest route would be for you to upload the patches for review and then go through a couple of iterations until it's cleaned up. Do you want to go that route? If not you can upload them anyway and whenever I get some spare cycles I can take it over and get it committed. But that might be slower since I have other things on my plate at the moment so I'm not sure when I'll be

Nice and why are you trying blake2 instead of a faster hash algorithm? And do you have any guess as to why xxHash64 wasn't faster than SHA1? I still have to see how many collision I get with it, but it seems so improbable that collisions on 64 bit hashes would be the problem. On 30 Jan 2018 18:39, "Zachary Turner" <zturner at google.com> wrote: It turns out there were some

Today I played around replacing the sha1 with xxHash64 and the results so far are bad. Linking times almost doubled and I can't really explain why, the only thing that comes to mind is hash collisions but on type names they should be very few in 64bit hashes. Any reason why you are trying blake2 and not murmurhash3 or xxHash64? About creating a pdb per lib, you can say to msvc to put the pdb

You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), but all these per-lib PDBs would have to be merged into a single master PDB at the end, so you still can't avoid that final . In a way, that's similar to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to eliminate the cost of merging types and symbol records) and we know what the problems with