Crashpad support for large-page PDBs

15 views
Skip to first unread message

Bruce Dawson

unread,
Feb 1, 2023, 5:33:03 PM2/1/23
to Crashpad-dev
Windows PDBs have, for decades, had an internal page size of 4 KiB. This limits them to 4 GiB which is a limit that Chrome is approaching (some test binaries have crossed it).

New versions of Visual Studio, windbg, WPA, dbghelp.dll, etc. all support larger pages so I would like to switch Chromium builds to use 8 KiB pages. I tested dump_syms.exe and it handle chrome.dll.pdb build with 8 KiB pages with no difficulty. Is there anything else I should do to test crashpad-related utilities before making the switch?

Also, does anybody know why crashpad handles these? Does it use some other tool that was upgraded? Was it upgraded? Did it always handle larger pages?

Mark Mentovai

unread,
Feb 1, 2023, 5:36:01 PM2/1/23
to Bruce Dawson, Crashpad-dev
Crashpad doesn’t touch PDBs directly. In our pipeline, they’re only handled by dump_syms (which is a DIA client, so it should be fine) and lldb. You might want to check to see if lldb can handle this change, but as far as Crashpad is concerned, you’ve got the all-clear.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/1e668ee5-eebd-4060-8496-442242f17b8fn%40chromium.org.

Bruce Dawson

unread,
Feb 1, 2023, 5:43:21 PM2/1/23
to Mark Mentovai, Crashpad-dev
I thought it might be DIA that did the PDB handling. Our current toolchain package still uses a fairly old version of DIA. I ran regsvr32 on the old version to try to make sure we were using it:

c:\src\chromium\src\third_party\depot_tools\win_toolchain\vs_files\1023ce2e82\DIA SDK\bin\amd64>regsvr32 msdia140.dll

but I didn't trust that so I also checked to see what version of msdia140.dll was loaded into dump_syms.exe. That checked out, so maybe msdia140.dll has always handled this correctly.

I could investigate lldb, although I'm not sure if that would be a blocker or just something that would need fixing if it doesn't handle them, but doesn't lldb consume the crashpad .sym files?
--
Bruce Dawson, he/him

Mark Mentovai

unread,
Feb 1, 2023, 5:58:54 PM2/1/23
to Bruce Dawson, Crashpad-dev
lldb eats PDB files directly, with much better debugging fidelity than what Breakpad’s dumped symbol format can carry. PDB support for lldb was initially written by Zach Turner a few years ago. https://github.com/llvm/llvm-project/tree/main/lldb/source/Plugins/SymbolFile/NativePDB, https://llvm.org/docs/PDB/.

We might be able to answer the question through inspection. Underlying MSF support is at https://github.com/llvm/llvm-project/tree/main/llvm/lib/DebugInfo/MSFhttps://llvm.org/docs/PDB/MsfFile.html. MappedBlockStream.cpp doesn’t appear to have a fixed block (page) size, so that’s good, but the LLVM MSF doc page also says:

LLVM only supports 4096 byte blocks (sometimes referred to as the “BigMsf” variant), so the rest of this document will assume a block size of 4096.

so maybe it’ll take some trial and error.

lldb support probably doesn’t block this switch, but we should talk to the crash team about this. And it should be fixable either way.
Reply all
Reply to author
Forward
0 new messages