[PATCH] D41825: [Docs][PDB] Update MSF File documentation

[Colden Cullen via Phabricator via llvm-commits]

colden added a comment.

In https://reviews.llvm.org/D41825#970042, @zturner wrote:

> In https://reviews.llvm.org/D41825#970040, @colden wrote:
>
> > In https://reviews.llvm.org/D41825#970033, @zturner wrote:
> >
> > > So each interval has exactly 4096 blocks.  Block 0 is only special in the first interval.  It's still there in every other interval, it just contains regular data.
> >
> >
> > But according to the code, that can't be true. Specifically, I'm looking at `llvm::msf::getFpmStreamLayout`. If you look at the loop assuming that `FpmBlock` is 1, then it pushes index 1 as the first FPM block, adds the result of `msf::getFpmIntervalLength` (which always returns 4096), and pushes that. This means that the second FPM in the sequence is at index 4097, which would mean that there are 4097 blocks in front of it. Unless block at index 4096 is unused, the first interval is in fact 1 block longer.
>
>
> Doesn't all of that match up exactly with the layout I posted?  Paste a copy of that layout diagram in my previous comment onto the end of itself.  4096 becomes "Data", 4097 becomes "FPM1", 4098 becomes "FPM2".  "Interval" is the distance between two consecutive blocks of the same FPM.  It's always 4096.  So FPM1 is on blocks 1, 4096 + 1, 4096*2 + 1, 4096*3 + 1, etc.  The blocks immediately before that (0, 4096, 4096*2, 4096*3, etc) are just data, with the only exception being block 0, which is the super block.


OOOOOH it just clicked. I thought the FPMs were always the first blocks in the interval, but having a block of data first makes so much sense.

Sorry for being so thick, and thanks for breaking it down for me. I'll post an update here in a minute.


Repository:
  rL LLVM

https://reviews.llvm.org/D41825