[PATCH] D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases

[Colden Cullen via Phabricator via llvm-commits]

colden added a comment.

In the process of writing this comment, I rewrote it like 8 times whenever I discovered something. So sorry if this reads disjointly :)

I'm 99% sure the NumBlocks includes the special blocks at the beginning, and the in-stride FPMs. I think this is what's actually causing the math in getNumFpmIntervals to be incorrect. What I still do not know is what transformations actually need to be applied, and to where.

After playing around with numbers, I do agree that the first FPM includes the 3 special blocks. Glad to see the MS code corroborates that.

My new theory is the in-stride FPMs include themselves. The first bit of the in-stride FPMs is actually just for itself. This is supported by the current coding placing the next FPM exactly 4096 blocks after the previous. This meshes well with the first-fpm-includes-special-blocks theory. Then the layout would be something like this:

| 0           | 1    | 2    | 3-4096         | 4097 | 4098-8192      | 8193 | 8194-12289     |
| Super Block | Fpm0 | Fpm1 | 4094 blocks... | Fpm  | 4095 blocks... | Fpm  | 4096 blocks... |
|

The last column is the part where this all falls apart, because if it does only store 4095 actual blocks per FPM, then it SHOULD be 4 intervals (the last one having 1 block).

The other thing I do not understand is how the Fpm1 actually works. I.e., if we're using Fpm0, does that mean that what would be Fpm1 is actually the first writable block? This would mean that the file layout could change significantly if you change Fpms; a block could overflow and require a new in-stride FPM to support the one extra block.

The way I see it, there are two options that would get a 12289-block file into 3 intervals:

1. When using Fpm0, Fpm1 is actually a writable block, and now we get 4095 blocks in the first stride, meaning the last one also only has 4095.
2. No matter what, the first in-stride FPM is always 4096 after Fpm1 instead of the in-use Fpm (usually Fpm0). In this case, the first in-stride FPM would actually be at block 4098, and that would get us another usable block in the first stride. (This is my favorite theory, as it results in the most layout stability)

I'll dig through the MS code a bit more and see if it becomes clear. It sure sounds like you have a better understanding of the MS code than I do, so maybe you can put the puzzle pieces together faster :)

As for repro, that's a tricky question, because I'm working with proprietary code, so I don't think I can just send you my .obj files. And because it requires such a specific number of blocks to be present, recreating it could be tricky. That said, if you have any ideas I'm more than happy to try them out locally. I can repro it 10/10.


Repository:
  rL LLVM

https://reviews.llvm.org/D41734