Do you know if there are any plans in LLVM to get thinlto to support debug fission?  If not, is this something we should do (future work)?

I build the chrome on kevin board.

With the -g1 flag, the debug file sizes are
-rw-r--r-- 1 root root 457701944 Nov  7 12:57 chrome.debug
-rw-r--r-- 1 root root 655987076 Nov  7 12:56 chrome.dwp

Without the -g1 flag, the sizes are
-rw-r--r-- 1 yunlian eng 1029380748 Nov  7 11:56 chrome.debug
-rw-r--r-- 1 yunlian eng 4199802476 Nov  7 11:56 chrome.dwp

I also measured the number of functions in the symbol files generated by dump_syms.
 
vanilla: 466648
g1:      457638


There are some cases that multiple functions are mapped to the same address. This is probably because of the icf (identical code folding) optimization.

The number of functions with unique address becomes:

vanilla: 343322
g1:      343317

So we lost 5 functions here.

Is there a way to test whether this breaks the crash server symbolization process?

One way to test would be to generate a local crash and then use the smaller symbol file to test.  Here are some documents that describes how to decode minidumps on Linux:
 - https://www.chromium.org/developers/decoding-crash-dumps
 - https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/linux_starter_guide.md

Including Mark and Joshua in case they know whether symbols generated using -g1 have sufficient information.

I generated the .dmp file of about:crash, about:inducebrowsercrashforrealz on kevin machine and run minidump_stackwalk with symbol files.

with/wihout -g1 flag gave me the same backtrace.

-g1 ought to be fine for what Breakpad needs to extract, but it’s not fine for developers who like to download debug symbols and locally debug a build, and it’s not fine for what we ultimately hope to do with debug info in Crashpad. -g1 omits information about, for example, function parameters and local variables.

Close this as won't fix because we won't go to this direction.