D51951 tried to fix https://bugs.llvm.org/show_bug.cgi?id=38847 by emitting the new fpo data stream to the PDB file. While I confirmed that that did indeed fix one known repro of this symptom, it turns out it didn't fix the one in the reporting bug.
The reason is that FPO data is emitted in two different places into the PDB, each with its own different format. The DBI stream contains a "new fpo" data stream and an "fpo" data stream (which I refer to as the "old" fpo stream). The New Fpo data stream is populated via the contents of the individual object files' DEBUG_S_FRAMEDATA subsections that appear inside of .debug$S sections. This is what modern compilers (both clang-cl and cl) emit. However, the bug in the report is about what happens if a crash occurs inside of memcpy. memcpy is written in assembler, and if you disassemble memcpy.obj from the CRT you find that it does not have a DEBUG_S_FRAMEDATA subsection in its object file. Instead, it contains a .debug$F section, which is something that until now there has not been a single reference to in the entire LLVM, Clang, or LLD codebase. However, some investigation into this shows that it is a trivial format, and is simply a list of FPO_DATA records. Furthermore, this section contains relocations, so unlike the manual relocating we needed to do with the DEBUG_S_FRAMEDATA contents, we just need to apply relocations to this section and copy it through.
But, as mentioned the format is slightly different and it does not go to the new fpo data stream, it goes to its own place.
With this patch I confirmed that the problem in the original bug report no longer reproduces. ChildFunction correctly shows up in my stack trace and I can switch to it and view local variables.